網站部分地區打不開怎麼排查？DNS、CDN與電信線路故障檢測方法

網站徹底打不開，很多時候反而容易排查。最麻煩的是另一種情況：自己存取一直正常，後台伺服器也沒有發出警報，但廣東、廣西或某個電信業者的使用者不斷回報網站打不開，有的人能正常進入，有的人卻一直連線逾時。

這種問題很容易被誤判，因為站長在自己電腦上重新整理十幾次都沒有異常，第一反應通常是「伺服器應該沒問題」。但使用者存取網站經過的不只是伺服器，還包括本地 DNS、電信業者網路、CDN 調度、TCP 連線、HTTPS、WAF 以及 CDN 回源等多個環節。任何一層出現地區性異常，都可能造成「部分地區打不開」。

真正有效的排查方法，不是馬上重啟伺服器，也不是只做一次 Ping，而是先確認故障分布，再按照 DNS → 網路線路 → TCP 埠 → HTTP/CDN → 來源站 的順序逐層縮小範圍。

一、先確認到底是哪些地區打不開？

收到使用者回報以後，第一件事不是登入伺服器，而是先弄清楚故障有沒有規律。

比如網站目前的存取情況是：

北京電信        正常
上海聯通        正常
浙江電信        正常
廣東移動        逾時
深圳移動        逾時
廣西移動        逾時

看到這樣的結果，基本就可以排除「整個網站已經掛掉」。因為如果來源站完全不可用，通常不會只有廣東、深圳、廣西移動出現問題，而其他地區仍然正常。

這時候應該把重點放到移動線路、區域 CDN 節點或者 DNS/CDN 調度上。

實際排查時，我更習慣先用 Chahu 做一次全國多節點網站測速，它可以同時觀察中國電信、中國聯通、中國移動以及港澳台、海外網路的存取結果，不需要站長分別尋找不同地區的電腦測試。目前其探測網路覆蓋 32 個國家、300+ 節點，並提供網站測速、Ping、DNS、TCPing 和 IPv6 等網路檢測功能。

這一輪不用急著糾結 30ms 和 50ms 誰更快，先看三個問題就夠了：哪些節點存取成功、哪些節點失敗、失敗節點有沒有明顯的地區或電信業者規律。

如果失敗節點隨機分布，而且每次測試位置都不同，更像是網站、來源站或者 CDN 穩定性問題；如果失敗節點高度集中在某個省份或某家電信業者，排查範圍反而更容易縮小。

二、部分地區打不開，先檢查 DNS 解析是否一致

如果故障明顯集中在部分地區，DNS 是我通常會優先檢查的一層。

很多人會覺得，同一個網域肯定解析到同一個位址。實際上，使用者使用的 Local DNS 不同，再加上 CDN 智慧調度、線路解析、DNS 快取等機制，不同地區拿到的 IP 完全可能不同。

例如：

北京電信     →  1.1.1.1     正常
上海聯通     →  1.1.1.1     正常
廣州移動     →  2.2.2.2     逾時
深圳移動     →  2.2.2.2     逾時

如果打不開的節點恰好都解析到 2.2.2.2，問題就已經很明顯了。接下來應該檢查這個 IP 對應的是不是異常 CDN 節點、舊伺服器位址，或者錯誤的線路解析記錄，而不是繼續盯著正常的 1.1.1.1 排查。

尤其是網站剛剛更換伺服器、切換 CDN、修改 A 記錄或 CNAME 後，更容易碰到這類情況。部分地區的 DNS 快取尚未更新，可能仍然存取舊位址，於是就出現新舊 IP 同時存在的現象。

透過多節點 DNS 查詢，可以重點比對 A、AAAA、CNAME 以及不同地區傳回的 IP。Chahu 的 DNS 查詢目前支援查看多節點解析記錄、IP 和回應時間，其站長工具中也提供 DNS 污染檢測和網域劫持檢測，可以繼續判斷異常是否來自解析層。

這裡有一個比較簡單的經驗：

如果正常地區和異常地區解析出的 IP 明顯不同，先查 DNS 和 CDN 調度；如果解析結果基本一致，再繼續往網路線路和埠方向查。

還要特別留意 AAAA 記錄。有些網站 IPv4 一切正常，但 IPv6 設定並沒有真正做好。如果部分電信業者或使用者網路優先使用 IPv6，就可能出現 IPv4 使用者正常、IPv6 使用者打不開的情況。Chahu 的 IPv6 網站測速也會檢查 AAAA 解析和 IPv6 存取表現，比較適合這種情境。

三、DNS 沒有問題，再看是不是電信業者或網路線路異常

如果幾個地區解析出來的 IP 都一樣，但存取結果仍然差異很大，下一步就應該看網路線路。

例如：

中國電信       基本正常
中國聯通       基本正常
中國移動       多地逾時

這種結果就比一個簡單的「網站打不開」有價值多了。

因為伺服器本身如果完全故障，三個電信業者通常都會受到影響。現在問題明顯集中在移動網路，就可以繼續檢查伺服器的 BGP 線路、移動方向路由、CDN 移動節點或者上游網路。

這時候可以先透過 Ping 看不同地區的延遲和丟包分布。Chahu 的線上 Ping 支援從不同電信業者和地區節點發起檢測，可以把逾時節點和正常節點放在一起比對。

不過這裡特別容易出現一個誤區：Ping 不通，不代表網站一定打不開。

Ping 使用的是 ICMP，有些伺服器、防火牆或者 CDN 本來就會限制 ICMP 請求。於是可能出現網站 HTTPS 一切正常，但 Ping 顯示逾時的情況。反過來也一樣，Ping 很快也不能證明網頁一定能正常打開，因為它沒有測試 443 埠、TLS 握手和 HTTP 請求。

所以 Ping 更適合用來觀察網路有沒有明顯的地區性差異，而不是單獨作為網站能不能存取的最终判斷依據。

四、Ping 正常但網站還是打不開，要繼續測 TCP 埠

這是很多人排查部分地區無法存取時容易漏掉的一步。

假設某個地區檢測結果是：

DNS 解析       正常
Ping          正常
TCP 443       逾時
網站 HTTPS     無法存取

這時候繼續研究 Ping 已經沒有太大意義了。

使用者存取 HTTPS 網站最終還是需要連線伺服器或者 CDN 的 TCP 443 埠。如果 ICMP 能正常到達，但 443 無法建立連線，就應該繼續檢查 TCP 網路、防火牆、CDN 節點或者埠存取策略。

TCPing 的作用就在這裡。

和一般 Ping 不一樣，TCPing 可以直接檢查指定 TCP 埠是否能夠建立連線以及連線耗時。Chahu 目前也提供 TCPing 檢測，用於檢查 TCP 埠連通性和建立連線所需時間。

排查網站時一般優先檢查：

HTTP      80
HTTPS     443

如果只有某些地區的 443 持續逾時，而其他地區完全正常，就要進一步考慮 CDN 節點、電信業者線路、防火牆 ACL 或上游網路策略。

假如 80 可以連線，443 卻不行，還需要重點檢查 HTTPS 相關設定，包括防火牆埠、TLS 服務以及 CDN HTTPS 設定，而不是簡單判斷成「網站伺服器掛了」。

五、網路能連通，再看 HTTP 狀態和 CDN 回源

DNS、Ping 和 TCP 都沒有明顯問題，並不意味著網頁一定正常。接下來需要真正發起 HTTP/HTTPS 請求，看網站傳回了什麼結果。不同 HTTP 狀態對應的排查方向差異很大。

傳回 403：先看 WAF、IP 和地區存取策略

如果打不開的使用者並不是連線逾時，而是能夠打開網頁，只是直接看到 403 Forbidden，說明請求實際上已經到達網站或 CDN。

這種情況下應該重點檢查 WAF、安全規則、IP 黑名單、Bot 防護、地區限制和存取頻率策略。

尤其是使用 CDN 或 WAF 的網站，有時候一個電信業者的大量使用者會共用某些 NAT 出口 IP。如果安全規則設定過嚴，可能把整批正常使用者一起識別成異常流量，於是就會出現「某些地區大量使用者打不開」的情況。

傳回 502、503、504：重點檢查 CDN 回源和來源站

如果異常地區大量傳回：

502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

問題往往已經不只是使用者到 CDN 這一段。

比如一個網站使用多個 CDN 節點：

廣州使用者
   ↓
廣州 CDN 節點
   ↓
回源連線異常
   ↓
504

而北京使用者可能被調度到另外一個 CDN 節點：

北京使用者
   ↓
北京 CDN 節點
   ↓
正常回源
   ↓
200

於是最终表現就是北京存取完全正常，廣州卻一直打不開。

這種情況應該繼續檢查異常 CDN 節點到來源站之間的網路、回源 IP、回源 Host、HTTPS 回源、來源站防火牆以及伺服器是否限制了 CDN 節點 IP。

如果大量地區同時出現 5xx，還要進一步檢查 Nginx、反向代理、PHP、Java、Node 服務、資料庫連線和伺服器負載，而不能一直把問題歸因於電信業者線路。

HTTP 狀態檢測最大的價值就在這裡：它可以幫助區分「請求根本沒有連到網站」和「已經連線網站，但網站主動傳回錯誤」。

六、根據故障現象，快速判斷應該查哪裡

實際處理這類問題時，我一般不會一項項把所有工具全部跑一遍，而是先看現象，再決定下一步查什麼。

把這些結果串起來以後，網站部分地區打不開的排查思路其實並不複雜：先確認哪些地區異常，再比較 DNS，然後檢查 Ping 和 TCP 連接埠，接著觀察 HTTP 狀態，最後才進入 CDN 回源和源站。

網站出現「部分地區打不開」，真正麻煩的地方從來不是工具不夠，而是容易把不同層的問題混在一起。站長自己可以存取，只能證明目前所在地區、目前電信業者到網站的鏈路正常，並不能代表全台使用者都正常。

遇到這類故障，先透過 Chahu 這類多節點檢測工具，把不同地區、中華電信、遠傳、台灣大哥大的存取結果放在一起比較，再根據異常節點繼續做 DNS、Ping、TCPing、IPv6 和 HTTP 檢測，通常很快就能判斷問題究竟更接近解析、電信業者線路、CDN 還是源站。與其反覆重新整理網頁或者盲目重啟伺服器，先把故障範圍縮小，往往才是處理區域性存取異常最快的方法。

常見問題

Q1：區域性存取異常會對網站的 Google SEO 排名產生什麼影響？

A： 如果抓取頻率較高的地區（如 Google 蜘蛛節點集中分布的北美或歐洲節點）剛好遇到網路逾時或傳回 5xx 錯誤，搜尋引擎會認為網站服務不穩定，進而降低抓取預算。若異常持續超過 24-48 小時，相關頁面的關鍵字排名可能下滑甚至暫時被索引移除。不過，如果是偶發的短時間節點波動，對整體 SEO 的影響非常有限。

Q2：如果確定是某個電信業者線路丟包嚴重，站長可以在伺服器端做什麼？

A： 電信業者跨網或單幹線故障通常難以由單台源站伺服器直接解決。最有效的做法是在 CDN 或 DNS 智慧解析層設定「線路分組」（按電信業者分流），將行動線路的流量調度到行動優化節點、BGP 多線節點或高防邊緣節點上，避開壅塞的骨幹網路互連節點。

Q3：為什麼有些地區 Ping 延遲很低，但開啟網頁時依然頻繁逾時？

A： Ping 使用 ICMP 協定，僅代表基礎網路層的回應速度；而載入網頁需要建立 TCP 連線並完成 TLS/SSL 握手（HTTPS）。如果伺服器的 TCP 全連接佇列溢出、防火牆策略誤殺特定 IP 的 443 連接埠，或者 SSL 憑證 OCSP 驗證在國內回應逾時，就會出現「Ping 正常但 HTTP(S) 請求被拒」的情況。

Q4：出現 IPv6 優先導致部分地區打不開時，應該如何緊急處理？

A： 如果確診是 IPv6 解析或環境設定問題，最快的緊急復原手段是在網域 DNS 後台暫時暫停或刪除 AAAA 記錄，強制所有地區的終端降級使用 IPv4 存取。隨後再排查源站 Nginx/Apache 的 IPv6 監聽設定（例如是否漏寫 listen [::]:443 ssl）或安全群組規則。

Q5：WAF 規則引發的區域性 403 攔截，通常有哪些隱藏原因？

A： 常見的原因是某些省份的電信業者在高峰期會使用大數量的 NAT（網路位址轉換）出口。當數千名不同使用者共享同一個公網 IP 存取網站時，極其容易觸發 WAF 的 Rate Limiting（頻率限制）或 Bot 識別規則，導致該地區所有使用該電信業者網路的使用者被「誤殺」攔截。