GCP實名帳號購買 GCP 域名綁定海外服務器無法訪問排查

第一章：現象先看清，別急著改配置

你把域名綁到 GCP 之後，在國內能打開，但換成海外服務器（例如美國、欧洲的 VPS）就訪問不了。這類問題表面像是“海外連不到”，實際上常常是“海外請求被錯誤導向”或“到達了，但在某一步被拒絕/握手失敗”。

排查一定要先把現象量化：海外服務器是完全超時，還是能連上但返回 4xx/5xx？是只有 HTTPS 失敗，还是 HTTP 也不行？瀏覽器報錯是證書不受信任、連線被重置，還是顯示找不到站點？

這些細節決定你接下來查的是 DNS、負載均衡、TLS，還是防火牆和路由。你如果一上來就改域名解析或動證書，很容易把原本能定位的線索打亂。

1. 先判斷是“解析問題”還是“連通問題”

用海外服務器做兩件事：第一，查 DNS 解析结果；第二，測試端口連通與 HTTP/HTTPS 行为。

DNS 解析可以用系統的 dig 或 nslookup。你需要記錄海外服務器查到的 IP 是什麼，以及是否跟你預期的 GCP 入口（例如 Global Load Balancer 的 IP、代理层地址）一致。注意：不同地區的解析可能不同，尤其是你用了 CDN、加速服务或某些基於地理的解析策略。

連通與回包可以用 curl 或 wget。如果 curl -v https://yourdomain 直接報握手错误，那优先查 TLS；如果是超时，那优先查路由、防火牆、或負載均衡是否在海外可用。

2. 只要有“海外可用性差異”，就要想到地理与策略

海外不可訪問，通常會落在幾個常見原因上：

• DNS 解析到非預期的 IP（例如解析到內網、旧地址、或某個地區策略导致不同结果）。
• 負載均衡/代理層配置不完整，例如缺少某些前端、轉發規則只對部分協議/端口生效。
• TLS 證書或 SNI/域名映射問題，導致握手對部分客戶端失敗。
• GCP實名帳號購買 防火牆或網路策略對來源地區不同（這在 GCP 通常不是“自帶地區限制”，但如果你自己做了策略或上了 WAF/安全服務，就可能出現）。
• 後端服務（例如 Compute Engine、Cloud Run、GKE）只允許特定來源或特定負載均衡器訪問。

把問題縮小到“哪一步掛掉”，才有可能快速收斂。

GCP實名帳號購買 第二章：DNS 不是只看“綁沒綁上”，要看“海外拿到的是什麼”

很多人驗證域名綁定，做的只是：在自己電腦上解析域名，看是否指向 GCP。可海外服務器使用的 DNS 解析器、是否启用本地緩存、以及你在權威 DNS 或上游做了智能解析，可能造成解析結果不同。

1. 用權威方式驗證解析鏈路

你需要做的是：從海外服務器查到的 A/AAAA/CNAME 是否與 GCP 入口一致。常見情況如下：

• 你把 A 記錄指向了某個地址，但那地址其實不是“全局負載均衡入口”，而是某個區域資源地址。國內可能恰好走到可用通路，但海外走另一條路被拒絕。
• 你使用了 CNAME 指向某個加速域名，但加速方對海外有限制或解析策略不同。
• GCP實名帳號購買 你同時配置了 IPv6（AAAA），但后端或負載均衡尚未正確支持 IPv6。部分海外網絡優先使用 IPv6，導致連線失败。

因此你至少要記下：海外解析出的 A/AAAA/CNAME 指向了哪裡。

2. 留意 TTL 與緩存：你改了但海外還在舊快照

域名變更存在傳播時間。TTL 設得太高時，海外解析器可能需要更久才能更新。你可以在海外服務器上反覆測試並觀察解析是否一致。

如果你已經明確改過解析，仍然海外訪問失敗，而國內成功，那就很像：海外 DNS 還沒更新，或者你改的是一部分記錄（例如只改了 A，忘了改 AAAA 或別名記錄）。

3. 比對“海外解析 IP”和“GCP 前端應有的入口”

如果你使用的是 GCP 的 Global External HTTP(S) Load Balancing，通常會有一個或一組用於綁定域名的 IP（或由 GCP 管理的入口）。你不應該讓域名解析到後端 VM 的私網/外網地址，除非你就是走直連 VM 並確保防火牆完全放行。

你要做的比對很簡單：域名在海外解析出來的 IP，是否就是你負載均衡的外部前端地址。若不一致，後面排查再多也沒用，因为流量根本沒進到正確的入口。

第三章：HTTP/HTTPS 行為差異是關鍵線索

只看“能不能打開”，資訊太少。你要把失敗分解到“哪種請求失敗”。

1. HTTPS 握手失敗：優先查證書與 SNI

如果海外服務器上 curl -v 出現类似“SSL routines:... handshake failure”或“certificate verify failed”，那問題多半落在 TLS 層。

GCP實名帳號購買 GCP 常見做法是：使用 Managed Certificate 或自建證書；再在負載均衡的 Target HTTPS Proxy 中關聯。對於多域名或多前端，你要確認：

• 證書覆蓋的域名包含你的 host（通配符或 SAN）。
• 負載均衡前端選擇的證書對應正確的前端規則。
• 如果你啟用了 HTTP->HTTPS 重定向，重定向是否正常、是否循環。

海外客戶端通常使用不同的 TLS 堆棧版本，這會讓“看起來國內能用”的配置問題暴露得更快。例如證書鏈不完整、使用了過舊的加密套件、或 SNI 未正確匹配，都可能導致握手失敗。

2. 能連上但返回 404/403：多半是轉發規則或後端健康檢查

如果 curl -v 能拿到回應，但回 404，通常代表負載均衡或後端服務對路徑處理不匹配。回 403 則可能是：

• Cloud Armor/WAF 規則擋住了來源。
• 後端服務只允許特定 Host Header 或特定來源。
• 安全策略（例如 IAP、API Gateway）要求特定憑證。

404/403 的差異也可以幫你判斷是否真的走到了你期望的負載均衡。

3. 直接超時：優先查防火牆、後端健康、以及跨網路路由

超時的典型原因包括：後端实例健康檢查未通過導致沒有可用后端；或防火牆/網路標籤不允許負載均衡器連到後端；或你的後端服務只在某些網路/區域可達。

注意：健康檢查未通过時，負載均衡可能仍返回某些狀態碼或直接超時，具體取決於你配置的回應策略與後端狀態。

第四章：在 GCP 里查日志與健康狀態，先確認“流量到底到了哪裡”

DNS 和客戶端測試只能告訴你“外面看起來不行”。要真正修好，你要用 GCP 的觀測能力看：請求是否進到負載均衡？是否命中前端規則？後端健康是否正常？

1. 查負載均衡的健康檢查（Health Check）

如果你用的是 HTTP(S) Load Balancer，背後依賴健康檢查來選擇後端。健康檢查失败最常見的原因有：

• 後端服務只在某個端口或路徑返回 200，但健康檢查用了不同端口/路徑。
• 防火牆阻止了健康檢查探測。
• 後端服務對 Host header 或請求頭有嚴格要求，導致健康檢查實際拿到非預期。

當健康檢查狀態不正常時，你可能遇到“國內偶爾通、海外必掛”的情況：因為不同地區的探測與路徑讓後端可用性看起來不一致（尤其是你還用了多區域、或部分區域後端狀態不同）。

2. 查負載均衡的存取日志（Access Logs）

打開或檢查負載均衡的 access logs，你能看到請求是否進來、協議是 HTTP 还是 HTTPS、狀態碼回了多少、延遲大概落在哪個階段。

如果海外請求根本沒有任何日志，基本可判定：流量根本沒進到你的 GCP 入口。這時就回頭查 DNS 解析與外部網路可達性。

如果海外請求有日志，但狀態碼大量是 403 或 404，那就查匹配的 URL map / backend service / path rules 是否正確。

3. 查後端服務自身的日志

負載均衡跑起來後，仍可能是後端服務拒絕或故障。你要確認後端收到的请求是否和你預期一致，包括：

• Host header 是否是你的域名。
• 是否走了正確的路徑與應用分支。
• 是否出現跨區域延遲或連線耗盡。

尤其在 Cloud Run、GKE Ingress 等場景，環境變量、服務授權策略、或網路出站策略可能只在特定條件下工作。

第五章：海外訪問失敗的常見“坑位”，一個個對照修

下面這些是實務中最常見的原因。你可以按順序排查，通常能在半天內定位。

坑位 1：只配了 IPv4，海外網絡強制走 IPv6

如果你的域名同時有 AAAA 記錄，但負載均衡或后端並沒有支援 IPv6（或配置不完整），部分海外客戶端會優先走 IPv6，結果就是“看起來海外不行”。

修復方式通常是：

• GCP實名帳號購買 確認 GCP 前端是否啟用了 IPv6。
• GCP實名帳號購買 或直接移除 AAAA，確保外界只能走 IPv4。

你需要小心：移除 AAAA 也要等 TTL 傳播完成。

坑位 2：域名綁定用錯了“類型”，導致只對本地有效

有些人把域名解析到錯誤的地址類型，例如把域名綁到某個區域 IP、某個測試環境、或把 CNAME 指到了不穩定的別名。國內因為路由或緩存差異可能“恰好可用”，海外則不行。

修復就是回到規格：你要確保域名解析目標是你實際承接流量的入口（通常是全局負載均衡的前端）。

坑位 3：重定向規則造成海外使用者落入循環

GCP實名帳號購買 某些配置會在 HTTP->HTTPS 或 path rewrite 中產生循環重定向。瀏覽器有時容忍但 curl 明確報錯，且海外延遲更高，重定向更容易觸發超时或被中間設備打斷。

你可以用 curl -IL https://yourdomain 看重定向鏈條。如果出現反覆跳轉、或跳轉到不正確的域名/協議，就先修掉重定向邏輯。

坑位 4：TLS 證書未就緒或鏈不完整，只在部分客戶端暴露

Managed Certificate 有簽發與驗證的延遲期。在簽發尚未完成時，國內可能因為緩存或證書暫存而表面可用，但海外客戶端更容易拿到“當前不可用”的狀態。

你要核對證書狀態是否完成（Active），並檢查證書能否在海外測試機上正確驗證鏈。

坑位 5：安全策略擋掉海外來源（尤其是 Cloud Armor/WAF/自建防火牆）

如果你在 GCP 上加了 Cloud Armor 或其它 WAF，規則往往是按照條件匹配（來源 IP 段、國家/地區、Header、JWT claims）。你可能只在國內測試，結果規則對海外段落命中了拒絕策略。

修復方式是：先在 Cloud Armor/WAF 的 logs 裡確認拒絕原因，再調整放行條件或提高可觀測性（例如增加一條 allow 但可記錄的策略）。

坑位 6：負載均衡到後端的防火牆不允許，導致健康檢查在部分區域失敗

即便你能從外部訪問到負載均衡，後端如果不可達也會導致服務不可用。更麻煩的是：你可能配置了某些後端網段，或某些區域的实例有不同的網路標籤/防火牆規則，造成海外流量落到特定後端時失敗。

排查建議：

• 逐區域檢查后端实例狀態與健康檢查結果。
• 檢查防火牆的 target tags/service accounts 是否匹配。
• 確認後端監聽端口與健康檢查端口一致。

第六章：一套可落地的排查流程（照做就能縮小範圍）

下面給你一個“從外到內”的流程。你可以把每一步的輸出記下來，通常 3-5 步就能鎖定根因。

步驟 1：海外機器上做 DNS 解析核對

記錄海外解析出的 A/AAAA/CNAME。把結果與你在 GCP 里配置的入口（負載均衡前端 IP/別名）對比。若不一致，直接回 DNS 配置，不要再猜其他層。

步驟 2：海外機器上做連通測試

用 curl -v http://yourdomain 和 curl -vk https://yourdomain 分別測。關鍵是看：是否超時、是否有握手、回了什麼狀態碼。

如果 HTTPS 連不上但 HTTP 有回應，優先查 TLS。

步驟 3：檢查負載均衡健康檢查與可用後端數

在 GCP 控制台或通過命令行查 backend service 的健康狀態。確保健康檢查在海外可用（至少在你預期路徑上健康）。

步驟 4：查看負載均衡 access logs，確認請求是否命中

若海外請求完全沒有命中日志，代表流量沒進入口；若命中但回 403/404，則查 URL map、path rule、Host header 處理。

步驟 5：最後才查後端應用日志與安全策略

如果負載均衡顯示已轉發到後端，但後端回錯，那就查應用層。例如應用是否要求特定 Header、是否對海外網段封禁、是否因為環境變量或配置導致差異。

第七章：修復後如何驗證“海外真的好了”

修復不是只在自己電腦上驗證就結束。你要用同一套方式，從海外測試機上重新做 DNS、連通、以及重定向鏈和狀態碼核對。

驗證點清單

• DNS 解析結果是否已與預期一致（A/AAAA/CNAME）。
• HTTPS 是否正常握手，證書是否可驗證且域名匹配。
• 狀態碼是否穩定（例如 200/302 正常，避免 403/404/5xx）。
• 延遲是否在合理範圍內，沒有超時或重試風暴。
• 重定向鏈是否停止在正確的目標 URL。
• 負載均衡日志與後端日志是否顯示請求被正確處理。

當你滿足以上條件，才算“海外可訪問”真正修好。

結語：把問題拆開，你會更快修到真正的根因

“GCP 域名綁定後海外服務器無法訪問”並不神秘。它常見於 DNS 解析差異、IPv6/證書/TLS 層問題、或負載均衡與後端之間的配置不一致。你越是用“能不能打開”這種模糊標準，你越容易在錯的方向上投入時間。

只要你沿著“海外拿到什麼 IP → 用哪種協議連上了嗎 → 負載均衡是否命中並健康 → 後端是否正確處理 → 安全策略是否擋住”，就能穩定收斂。修好一次，後面再遇到類似問題，你會更快定位，體感會明顯提升。