IP 定位不準？如何排查並修正錯誤的地理位置

重點摘要

• 「位置不對」可能出自三個不同的來源：IP 地理位置資料庫、瀏覽器 Geolocation API，或是網站先前儲存的你的資料。改錯了層，什麼都不會變。
• 每個網站使用的資料庫各不相同，所以先看看你的 IP 在多家服務商那裡分別是什麼結果，並弄清楚出問題的網站用的是哪一家。
• 一般使用者可以向各家服務商分別提交更正；生效要等服務商的更新週期，通常需要數週。
• 掌控該位址區段的人可以發布 geofeed（RFC 8805），並在註冊紀錄中引用它（RFC 9092）。這是唯一能把真實資訊一次推給所有使用方的辦法。
• 行動電信業者、企業與雲端出口、衛星連線，以及 VPN 或中繼，都不是你能「更正」的錯誤。

步驟 1：弄清楚是哪一層出了問題

人們說「我的 IP 位置不對」，其實可能是指三件互不相干的事：

1. IP 地理位置資料庫對你的 IP 怎麼說。 這是伺服器端的估算，不需要任何授權。本指南能改善的只有這一層。
2. 瀏覽器 Geolocation API 怎麼說。 以 GPS 或 Wi-Fi 定位，需要權限提示授權，通常很準。如果地圖能精確到你所在的街道，來源是它，而不是你的 IP。
3. 網站儲存了你的什麼資料。 帳號所在地區、帳單國家、儲存的收件地址，或上次造訪時寫入的 Cookie。即使你的 IP 早已不指向那座城市，網站仍可能顯示舊城市。

如果只有登入後才顯示錯誤位置，或換了網路錯誤依舊，就懷疑第 3 層，去修改帳號或個人資料設定，任何資料庫更正都動不了它。第 1 層如何得出位置（註冊機構配置、商業資料庫、WHOIS、拓樸推斷），請看 IP 地理位置的準確度；本文談的是怎麼做，而不是原理。

步驟 2：確認真實情況

開啟 IP 情報查詢，記下你的公開 IP 以及它對應的國家、地區與城市。接著再用兩個以上彼此獨立的地理位置查詢來對照。各家服務商的結果經常不一致，而網站只會查詢其中一家。

你要看的是：

• 所有服務商一致且正確。 你的 IP 沒問題，問題出在第 2 層或第 3 層。
• 所有服務商一致但錯誤。 很可能是註冊機構或位址配置層面的問題，下面的 geofeed 路線最重要。
• 服務商之間不一致。 只有部分資料庫已經過時。要先弄清楚出問題的網站用的是哪一家（通常能在其隱私權政策中看到，或向客服詢問），才談得上修正。

也要看看你的 IP 最近是否變過。新位址可能繼承上一位持有者的過時資料，參見為什麼你的 IP 位址總在變。

步驟 3：向服務商提交更正

對一般使用者來說，現實可行的辦法就是告訴資料庫。多數主流地理位置服務商都有公開的更正或「更新我的 IP 位置」表單，少數也接受網路營運方直接提交。這裡不放連結，你可以搜尋服務商名稱加「correct IP location」。

需要有這些預期：

• 必須逐家通知。 在一家修正，不會傳到其他家。
• 需要時間。 更正隨服務商的更新週期生效，通常是幾天到幾週，而不是幾分鐘。
• 說得具體。 提供 IP 或網段、你認為正確的位置，以及可供查證的依據，例如你的 ISP 名稱與服務範圍。
• 幾週後複查，用當初顯示錯誤的同一個查詢。

如果位址由 ISP 配發，也請聯絡 ISP：服務商讀取的註冊資料掌握在他們手裡，網路營運方提交的更正比終端使用者的更有份量。

步驟 4：發布 geofeed（如果你掌控該位址區段）

如果你營運網路、代管服務，或擁有自己位址空間的企業，有一條權威途徑。geofeed 是你自己發布的純 CSV 檔案，把你的網段對應到地理位置。RFC 8805 定義了格式：每行一個網段，以 # 開頭的行是註解。

# prefix, country, region, city
192.0.2.0/24,US,US-CA,San Francisco
2001:db8::/32,DE,DE-BE,Berlin

國家用 ISO 3166-1 alpha-2 代碼，地區用 ISO 3166-2 代碼，城市寫一般名稱；如果只想提供國家層級的資料，後面的欄位可以留空。（範例網段是保留的文件用位址。）

單獨一個檔案只是一份聲明，使用方需要找到它，並確認它來自位址持有者。RFC 9092 規定了做法（後來由 RFC 9632 更新，思路不變）：把 geofeed 的 URL 掛在該位址區段的註冊紀錄上，也就是在區域註冊機構的 whois/RPSL 資料裡加入 geofeed: 屬性或一行 remarks: Geofeed。支援 geofeed 的服務商會順著註冊紀錄中的引用去抓取檔案。由於只有該區段的維護者能編輯註冊紀錄，這個指標本身就能證明檔案出自誰手；RFC 也定義了選用的 RPKI 簽章，供希望把檔案與位址持有者做密碼學綁定的營運方使用。

意義在於：這是唯一能把真實資訊一次推給所有使用方的機制，而不是一張更正表單一張表單地填。需要如實說明的限制是：是否採用由各服務商自行決定，所以生效既不是即時的，也沒有保證；當你搬遷或重新編號網段時，geofeed 也必須同步更新。引用之前，請先檢查檔案的語法錯誤。

步驟 5：無法修正的情況

有些「錯誤」位置其實是網路依設計在運作，追著改只是浪費時間：

• 行動網路與電信業者級 NAT。 你的流量從區域匯聚點出去，那裡可能在另一個城市或省分。
• 企業、大學與雲端出口。 你顯示在總部或資料中心所在區域，而不是你的座位。
• 衛星連線。 一個地面站可能涵蓋極大的範圍。
• 剛被重新配發的位址區段。 資料庫有落差，只有上面的更正與 geofeed 路線能縮短它。

各自的原因請看 IP 地理位置的準確度。如果問題出在行動電信業者，實際的做法是：凡是需要你真實位置的場景，都依賴瀏覽器基於授權的定位。

步驟 6：VPN 或中繼正在做它該做的事

如果你在用 VPN、代理，或 iCloud 私密轉送這類隱私中繼，顯示的不是你的真實位置，恰恰說明它在正常運作，參見隱私工具比較。在提交任何更正之前，先中斷連線，再執行一次 IP 查詢。

還有一點要知道：只有 IP 變了時，瀏覽器仍會回報你真實的時區與語言。它們與 IP 所在地對不上，本身就是一個偵測訊號，參見時區與語言洩漏與網站如何偵測 VPN。所以更正的目標是讓你真實的連線得到準確的位置，而不是換成另一個。

從頭到尾的檢查清單

1. 判斷是哪一層出錯：資料庫、瀏覽器 Geolocation API，還是帳號中儲存的資料。
2. 如果是儲存的資料，修改帳號或資料設定，到此為止。
3. 中斷任何 VPN、代理或中繼，開啟 IP 情報查詢，讀取你的 IP 與顯示的位置。
4. 與另外兩個地理位置查詢對照，記下哪些是錯的。
5. 弄清楚受影響的網站用的是哪個資料庫。
6. 向每個出錯的服務商提交更正，附上網段與可查證的位置。
7. 如果你掌控該位址區段，發布 RFC 8805 格式的 geofeed，並在註冊紀錄中引用它（RFC 9092 / RFC 9632）。
8. 排除 CGNAT、企業或雲端出口以及衛星連線；如果屬於其中之一，就別再更正了。
9. 等幾週，用同樣的查詢複查。

常見問題

更正後的 IP 位置要多久才會顯示？

通常是幾天到幾週，取決於各服務商的更新週期。每家服務商都要個別更正，所以不同網站的更新時間也不同。

為什麼手機和筆電顯示的城市不一樣？

手機可能走的是行動電信業者網路，流量經區域閘道轉送，而筆電用的是家用寬頻。兩個位址各自被定位，電信業者的位址常常指向閘道所在的城市。

我能自己改變 IP 位置嗎？

對於資料庫裡錯誤的項目，你可以透過服務商表單或 geofeed 來更正。本指南不涉及讓網站相信你在別處；VPN 或中繼是公開地做這件事，代價見上文。

瀏覽器定位和我的 IP 位置是一回事嗎？

不是。瀏覽器 Geolocation API 在你授權後使用 GPS 或 Wi-Fi，通常很準。IP 位置是無需授權的估算，最多精確到城市。