朋友 VPS 的 IP 被 Google 送中，親測 3 天就拉了回來

朋友的一臺美國 VPS 在加州 Fremont，IP 也是美國的，可是 Google 把它判成了中國大陸。被判成中國大陸之後，Gemini 打開就是地區不支持，YouTube Premium 也訂不了，Google Play 同樣鎖在中國區。你有沒有碰到過這種事，VPS 明明買在美國，Google 卻把你當成中國大陸用戶？

這個判定是能改回來的。我寫了一個小工具，用目標地區的流量把這個 IP 的區域畫像一點一點喂回去。cron 每 20 分鐘跑一輪，跑了大約 3 天之後，這個 IP 就被 Google 判回了美國。

送中是什麼意思

「送中」是圈子裏對這件事的叫法：一臺數據中心或者 VPS 的 IP，物理位置在美國、日本這些地方，Google 卻把它判給中國大陸。IP 的註冊信息明明寫着美國，但是 Google 的服務不認這個註冊地。於是搜索、應用商店、訂閱服務這些 Google 的服務，全按中國大陸的規矩來處理這個 IP。

被送中之後，具體壞在哪

出問題的不是某一個頁面。這個 IP 在 Google 眼裏的整個地區身份都是錯的，所以凡是按地區放行的服務都會跟着出問題。具體是這樣：

1. Gemini 用不了，打開就提示所在地區不受支持。
2. YouTube Premium 訂不了，訂閱的時候會被按中國大陸地區處理。
3. Google Play 鎖在中國區，能裝的應用和價格都跟着中國區走。
4. Google 搜索的結果和服務區域，全部按中國大陸來。
5. 其他按地區放行的 Google 服務，同樣跟着這個判定走。

賬號也會跟着受影響。短期借這個 IP 上一上網的話，壞的只是體驗。可是如果你長期拿這個 IP 登錄自己的 Google 賬號，那麼賬號的常用地區也會跟着這個 IP 漂。時間長了，賬號本身就多一層被判成異常地區的風險，所以這件事能處理就儘早處理。

IP 爲什麼會被判到中國去

Google 給一個 IP 定地區畫像的時候，不只看註冊數據。註冊信息只是底子，Google 還會看行爲信號，也就是這個 IP 長期在發什麼樣的流量、它所在的網段是什麼樣的使用環境。

如果一個 IP 長期被拿去當代理或者 VPN 的出口，那麼從它出去的流量大多是中文語境的，在 Google 眼裏，它就是一個被中國大陸用戶用着的地址。還有兩種情況也很常見。一種是機房 IP 的前任租戶留下的使用痕跡：那個 IP 的流量構成早就偏了。另一種是整個網段的用戶本來就以中文用戶爲主，這個 IP 只是跟着網段一起被喂偏的。

這些信號喂得久了，行爲畫像就壓過了註冊信息。所以你去查 IP 數據庫，就算上面寫着美國，也沒有用。Google 判地區的時候，看的主要是行爲信號，註冊信息反而排在後面。

拉回來的原理

既然畫像是被流量一點一點喂偏的，那麼拉回來的辦法，就是用目標地區的流量一點一點喂回去。喂的內容要像當地居民真的在用網，所以語言要用目標城市通用的語言，定位也要落在目標城市的座標上，搜的詞也要是當地當天的熱搜詞。這樣的請求持續發上一段時間，Google 的行爲判定就會慢慢漂回目標地區。

怎麼知道漂回去了沒有？看三個探針就夠了。所謂探針，就是拿三個能直接看到地區判定的入口去問 Google。第一個看 google.com 會把你跳轉到哪個國家的域名。第二個看 YouTube Premium 顯示哪個地區。第三個看 YouTube Music 顯示哪個地區。三路都翻回目標國家，這個 IP 纔算真的回來了。

還有一條官方的路，是給 Google 提交 IP 更正表單，把被判錯的 IP 和它實際所在的國家填上去。但是 Google 自己在說明裏寫了，處理可能要一個月以上，而且不會單獨回覆你。所以這條路只能當保底，不能指望它來解決眼前的問題。

我把工具拆出來重寫了一版

被送中的是朋友的機器。我幫他處理這件事的時候，找到了 hotyue 的 IP-Sentinel 這個項目，它的 Google 模塊就是處理送中的。我把那個模塊單獨拆出來重寫了一版，起名 ip-reanchor，開源在 GitHub 上：https://github.com/alexliyu7352/google_ip 。

這一版只做一件事，就是把被判到中國的 VPS IP，用目標地區的本土流量長期喂回來。每輪養護跑起來，是這麼一套動作：

1. 人設先定死。工具先按出口 IP 算一個哈希，再用這個哈希固定對應到 3 臺「家庭設備」，每輪從裏面抽一臺用。還有一處細節容易露餡：請求的 TLS 指紋要和聲稱的瀏覽器版本對得上，所以這一版用 curl_cffi 的 impersonate 功能，指紋按目標瀏覽器生成。這樣 UA 寫哪個版本，指紋就跟到哪個版本，兩個版本始終綁在一起。

2. 住址也定死。工具同樣按 IP 的哈希，在目標城市的中心座標周圍 1.3 公里以內定一個虛擬住址。住址定下來之後跨輪不變，每個動作只在這個住址附近再抖動 11 米，爲的是模擬定位的自然漂移。原版的做法是每一輪在 3 公里範圍裏重新擲一個住址，那等於每 20 分鐘搬一次家，真住戶不會這樣，所以這一版把這一點改掉了。

3. 詞庫每天更新。工具每天去拉 Google Trends 上目標國家當天的熱搜詞，再和自帶的種子詞庫合併，最後保留 100 條。所以每一輪搜的詞，都是當地人當天真的在搜的東西。

4. 一輪做 5 到 8 個動作。動作在 Google 搜索、Google News、Maps 座標搜索、低風險的生態頁面和平臺連通性檢查之間按權重抽。生態頁面指的是 about.google、safety.google 這類 Google 自家的頁面。每個動作之間隔 45 到 75 秒。相鄰兩個動作是同一類的時候，有 70% 的概率帶上 Referer，看起來像在站內點來點去，而不是憑空敲網址。

5. Cookie 按 IP 存盤。每臺設備用的 Cookie 都按出口 IP 存成文件，下一輪接着用。所以在 Google 眼裏，來的是一個連續的老訪客，而不是一批每次都從零開始的新面孔。

6. 每輪末尾自檢。一輪跑完，工具把三路探針再查一遍，再把結果追加進 probe_history.jsonl 這個文件裏。翻開這個記錄，哪一路還是 CN、哪一天翻回了目標國，都看得見。

一輪跑完，大概要 6 到 10 分鐘。這一版的形態也和原版不一樣。原版有一套 Master-Agent 中樞程序，外加 Telegram 通知和遠程執行，這一版就是單機上的一個文件。cron 定時跑，日誌和探針記錄也都留在本機，所以攻擊面小很多。

還有一條鏈路，這一版沒有保留。原版有一條「信用淨化」的路，靠訪問一批目標地區當地的白名單站點，主要是當地的新聞站點，去影響欺詐分數據庫。我查不到證據能證明訪問這些站點會影響那個數據庫，所以沒有把它搬過來，不做沒有依據的動作。

它僞造不了登錄用戶的真實定位，也僞造不了安卓手機的 GPS 和 WiFi 定位數據。還有，如果這個 IP 現在還在給大量真實的中文用戶當代理出口，那麼真人的信號會把工具這點信號淹掉，效果就別指望了。

親測：3 天，探針全部翻回美國

朋友的這臺 VPS 在美國 Fremont，是一個 IPv4 地址。11 月 7 日，探針給出的結果是 CN_LOCKED，三路全判 CN。三路就是 google.com 跳轉、YouTube Premium 和 YouTube Music，日誌裏分別記作 Jump、Prem 和 Music。確診之後，當天就掛上了 cron，讓它每 20 分鐘跑一輪。

到 11 月 10 日，探針翻成了 OK。三路的結果記作 Jump=US、Prem=US、Music=US，全判美國。從確診到翻回，前後大約 3 天。這個 3 天只是這一臺機器這一次的結果：我在工具的說明裏寫的預期是按周觀察，因爲每臺機器所在的網段環境都不一樣，要喂多久也會跟着變。這一臺 3 天就翻回來，說明它所在的網段環境對它比較有利。換一臺機器，就未必還是 3 天。

養護首日（11 月 7 日）和翻回當天（11 月 10 日）的兩張運行日誌截圖我放在下面，截圖裏的出口 IP 和經緯度都已經塗抹掉了。

怎麼用

第一步，把代碼拉下來裝好，裝在要養護的那臺 VPS 上。

git clone https://github.com/alexliyu7352/google_ip.git && cd google_ip
uv sync

第二步，先體檢，確診了再動手。

uv run python reanchor.py probe --region US-Fremont

先跑一遍 uv run python reanchor.py regions，全部 67 個城市的代碼就都能查到。上面 probe 命令裏的 US-Fremont，就是從這張表裏查出來的。

如果城市表裏沒有你要的點，或者你想精確錨到某個街區，那麼就直接給經緯度，用 —lat 和 —lon 成對傳。雙棧的機器記得加 —ipv4 或者 —ipv6 來把要養的那個地址鎖死。不然就會只養好 v4，v6 那個地址還留在錯誤判定裏。

第三步，把官方更正表單提交掉，當保底：

這個表單在 Google 支持頁面上就能找到，打開之後填被判錯的 IP 和它實際所在的國家就行。提交完不要等它，因爲 Google 的處理週期是一個月起步。這條線和腳本並行跑，哪條先到都行。

第四步，掛上 cron，每 20 分鐘跑一輪。

*/20 * * * *  cd /path/to/google_ip && $HOME/.local/bin/uv run python reanchor.py run --region US-Fremont >/dev/null 2>&1

程序內部還有 0 到 180 秒的隨機錯峯，所以不用再自己加 sleep。一天跑 72 輪，地區判定要靠這樣長期持續地喂纔會慢慢變，而單獨跑一輪看不出變化。

第五步，看趨勢，不要看單日。

每輪的三路探針結果都追加在 probe_history.jsonl 裏，隔幾天翻一翻，看 YouTube 那兩路的判定有沒有從 CN 往目標國挪。我自己在說明裏寫的就是按周觀察，所以一兩天沒動靜是正常的，不要因爲第一天沒翻回來就斷定沒用。

兩條注意事項，部署前先看

第一，手機絕對不要拿這個 IP 當 VPN 或者代理出口。安卓的 Google 框架會自己往 Google 發定位數據，它發出的這部分定位流量有可能不走 VPN 和代理的通道，你就算開了全局代理，它也一樣有可能繞過去。手機的真實位置會繞開代理、順着框架自己的通道源源不斷地餵給這個 IP，而工具喂的信號壓不過手機發出的定位信號，這個 IP 就拉不回來。

除非你在服務器端把 Google 框架的定位流量過濾掉，或者在手機上把 Google 框架的粗定位和精細定位都關掉，否則就別一邊拿手機掛這個 IP，一邊指望腳本把它拉回來。

第二，整個網段都送中的，拉不回來，所以別白費勁。先拿 probe 去探一探同網段的其他 IP，如果整個網段都判 CN，那就說明那個網段上有大量真實的中文語境流量在持續喂着這個判定。工具每 20 分鐘一輪的信號量，和整個網段其他人的使用量完全不在一個量級，所以工具這點信號會被淹沒，也就喂不出一個立得住的地區畫像。這種情況直接換 IP，或者換機房，不要在這種網段上耗時間。

Google 給一個 IP 定地區，靠的是它平時發出的流量記錄。它記着誰在用這個 IP，也記着這些人用的是哪裏的語言、定位座標落在哪裏，然後從這些記錄裏判它屬於哪裏。也因爲判定是這樣一條一條記錄累積出來的，所以它記錯了也能改：只要目標地區的流量長期持續地喂回去，新的記錄就會慢慢把判定帶回來。前提還是那一條，就是這個 IP 所在的網段沒有整個被送中。

如果這篇對你有用，請訂閱或收藏這個博客。我會繼續分享 AI、安全和開源方面自己動手查過、用過的東西。這個項目後面如果有新的實測結果，我再寫一篇把數據補上。