網站打不開了怎麼檢查？常見原因與完整排查方法

網站突然打不開，很多人的第一反應都是伺服器是不是掛了，接著就開始重啟伺服器、重啟 Nginx，甚至直接修改 CDN 配置。但實際做網站故障排查時，伺服器宕機只是其中一種情況。DNS 解析異常、CDN 節點故障、電信商線路波動、SSL 憑證錯誤、本地網路快取，甚至防火牆策略配置不當，都可能讓網站表現出「打不開」的現象。

尤其是遇到「自己打不開，別人正常」「電信能存取，行動打不開」「國內異常，海外正常」這類問題時，只看瀏覽器報錯基本很難直接判斷原因。所以網站打不開以後，最重要的不是馬上改配置，而是先確認故障範圍，再從網路、DNS、HTTP、CDN 和源站幾個層面逐步排查。下面就按照實際運維中比較常用的順序，介紹網站打不開以後應該怎麼檢查。

一、網站打不開，先確認到底是誰打不開

發現網站無法存取後，第一件事不是登入伺服器，而是先判斷故障範圍，因為「網站打不開」其實可能對應完全不同的問題。

如果沒有先弄清楚故障範圍，很容易排錯方向：比如網站只是在廣東行動網路下存取異常，你卻一直重啟伺服器，這類操作基本不會解決問題。比較合理的做法，是先從不同地區、不同電信商重新測試一次網站。

二、先用多節點測速確認網站是否真的無法存取

自己電腦上的存取結果只能代表目前這一條網路線路：比如你辦公室用的是電信網路，即使網站存取完全正常，也不能證明聯通、行動或者其他地區使用者存取時沒有問題。

排查網站打不開時，最簡單有效的方法是先使用 Chahu 網站測速工具進行多節點檢測。透過不同地區和電信商節點同時存取網站，可以快速看到網站目前的整體連通情況。實際測試時，不需要一開始就研究特別複雜的資料，先重點觀察下面幾個結果：

• 哪些節點可以正常存取

• 哪些地區出現逾時

• 是否集中在某一個電信商

• 回應時間是否明顯異常

• 國內和海外節點結果是否存在明顯差異

例如測試結果中，電信、聯通節點基本正常，但大量行動節點存取失敗，這種情況下就不太像伺服器整體宕機，更應該繼續檢查行動線路、DNS排程或者CDN節點。

如果所有地區幾乎全部逾時，則應該優先檢查源站、CDN、Web服務和伺服器網路。

還有一種情況也很常見：Chahu 多節點測試全部正常，只有你自己的電腦打不開。這種問題通常應該先檢查本地 DNS、瀏覽器快取、代理設定或者目前網路，而不是直接去動線上伺服器。

三、繼續用 Ping 判斷網路連通性有沒有異常

確定故障範圍以後，第二步可以檢查 Ping。Ping 最適合用來快速判斷網路基本連通情況，以及不同節點之間是否存在明顯延遲和封包遺失差異。如果只在自己電腦上執行 Ping，依然只能看到目前網路到目標伺服器的結果，所以更適合結合 Chahu 線上 Ping 做多地區測試。

在 Ping 結果中，主要看三個方面。

1. 大部分節點能不能收到回應

如果全國多個節點同時出現逾時，需要繼續確認：

• 伺服器 IP 是否線上

• CDN 節點是否異常

• 防火牆是否限制 ICMP

• 網路線路是否中斷

• 伺服器是否出現大面積網路故障

不過這裡需要注意，Ping 不通並不代表網站已經掛了。

部分伺服器、雲廠商或者 CDN 節點會主動封鎖 ICMP，因此不能只根據 Ping 結果判斷網站狀態。

2. 是否出現明顯封包遺失

如果測試結果中，大部分地區都沒有問題，只有少數地區出現持續封包遺失，就需要進一步檢查對應地區的網路線路。

比如：上海電信正常，北京聯通正常，但廣東行動出現大量封包遺失。

這種情況下，伺服器本身往往並沒有完全失聯，更可能是某段網路路徑或者電信商線路出現波動。

3. 延遲有沒有突然升高

網站以前存取延遲只有幾十毫秒，突然大量節點變成 150ms、200ms 甚至更高，也值得關注。

常見原因包括：

• 路由繞路

• 跨電信商網路擁塞

• CDN排程到距離較遠的節點

• 伺服器出口網路異常

• 部分骨幹線路出現波動

所以 Ping 更適合用來確定「網路是不是有問題」，而不是直接判斷網站頁面本身是否正常。

四、Ping沒問題，再檢查DNS解析是否正常

很多網站打不開的問題，實際上不是伺服器掛了，而是域名沒有解析到正確的位置。使用者存取網站時，並不是直接連接伺服器，而是先透過 DNS 把域名解析成 IP 位址，再存取對應伺服器或者 CDN 節點。

如果 DNS 這一層出現異常，即使伺服器本身完全正常，使用者依然可能打不開網站。

這時候可以透過線上DNS 查詢工具檢查目前域名的解析情況。

重點可以查看：

• A記錄

• AAAA記錄

• CNAME記錄

• NS記錄

• 不同地區傳回的IP

• 不同電信商解析結果是否一致

1. 域名完全解析不到IP

如果查詢不到正常的 A、AAAA 或 CNAME 記錄，可以檢查：

• 域名DNS記錄是否被刪除

• DNS服務商是否異常

• 域名狀態是否正常

• NS配置有沒有修改

• DNSSEC配置是否存在問題

2. 域名仍然解析到舊IP

這種情況經常發生在剛遷移伺服器或者更換 CDN 後。

例如網站已經從舊伺服器切換到了新伺服器，但部分地區 Local DNS 仍然快取著舊記錄，在 TTL 過期之前，部分使用者存取的依然是舊 IP。

於是就會出現：

有些人已經能開啟網站，有些人仍然打不開。

3. 不同地區解析結果差異很大

如果同一個域名在不同地區解析到了明顯異常的 IP，就需要繼續判斷：

• CDN智慧排程是否正常

• 是否存在DNS快取異常

• Local DNS是否出現問題

• 域名是否存在DNS污染或者劫持

如果網站表現為「IP可以直接存取，域名打不開」，DNS就是非常值得優先檢查的一層。

五、DNS正常，網站還是打不開怎麼辦

如果域名解析沒有明顯問題，Ping結果也比較正常，但網頁依然無法開啟，就應該把排查重點從「網路有沒有通」轉移到「網站服務有沒有正常回應」。重點檢查 HTTP、HTTPS、連接埠以及 Web 服務。

檢查80和443連接埠

普通網站最常見的存取連接埠是：

• HTTP：80

• HTTPS：443

伺服器可以 Ping 通，並不代表 Web 服務一定正常。

例如下面這些情況都會導致網站打不開：

• Nginx停止執行

• Apache服務異常

• 443連接埠未開放

• 雲伺服器安全群組修改

• 系統防火牆誤封連接埠

• CDN無法連接源站

• 源站連接埠配置錯誤

所以如果網路正常，但瀏覽器存取持續逾時，就需要確認網站實際監聽連接埠是否正常。

六、透過HTTP狀態碼判斷網站故障方向

網站並不一定要完全打不開。有時候瀏覽器還能收到伺服器回應，只是傳回了 403、502、503 或 504 等錯誤。不同狀態碼對應的排查方向也不同：

網站出現 502 時，通常就不需要把主要精力放在 DNS 上，而應該繼續檢查 Nginx、PHP、應用服務或者 CDN 回源；如果大量出現 504，則需要重點確認源站回應時間、伺服器負載、資料庫以及 CDN 回源鏈路。HTTP狀態碼雖然不能直接告訴你最終原因，但可以快速幫助縮小故障範圍。

七、只有部分地區打不開，要繼續查路由

網站整體沒有宕機，DNS解析也正常，但是某些地區或者電信商持續存取失敗，這時候網路路徑就比較值得檢查。

例如：

上海電信正常
北京聯通正常
廣州行動持續逾時

並且這些地區解析出來的 CDN IP 又基本一致。

這種情況下，問題可能並不在 DNS，而是在使用者到伺服器或者 CDN 節點之間的網路路徑。

可以利用 Chahu 的路由相關檢測繼續觀察資料包經過的線路。

排查時重點關注：

• 哪一跳開始延遲明顯升高

• 是否出現連續封包遺失

• 是否存在明顯路由繞路

• 是否集中在某個電信商

• CDN排程線路是否合理

例如原本廣州使用者存取香港節點，正常情況下路徑比較短，但實際路由卻繞到其他地區甚至海外再傳回，這時候即使伺服器本身沒有任何故障，存取體驗也可能明顯變差。

因此，如果網站只在某些地區打不開，路由檢測通常比反覆重啟伺服器更有價值。

八、檢查CDN和WAF

現在很多網站前面都部署了 CDN 或高防 CDN，所以使用者存取的往往不是源站，而是 CDN 邊緣節點。這種情況下網站打不開，不一定是源站的問題。

如果多節點測試顯示部分地區異常，可以繼續檢查 CDN：

• CNAME是否配置正確

• CDN節點是否出現故障

• 回源位址有沒有修改

• 回源連接埠是否正確

• 源站防火牆是否允許CDN回源IP

• HTTPS憑證是否已經同步

• 快取或者重新導向規則是否配置錯誤

如果開啟了 WAF，還要檢查安全策略有沒有誤傷正常使用者。

比較常見的問題包括：

• IP黑名單誤封

• 地區存取限制

• CC防護規則設定過嚴

• Bot策略誤判

• User-Agent過濾規則異常

• 請求頻率限制配置錯誤

有時候網站只有部分使用者打不開，並不是線路出了問題，而是安全策略把他們攔截了。

九、HTTPS網站打不開，還要檢查SSL憑證

現在絕大部分正式網站都已經使用 HTTPS，因此憑證異常也是比較常見的一類問題。

常見表現包括：

• 瀏覽器提示連線不安全

• NET::ERR_CERT_DATE_INVALID

• 憑證域名不匹配

• TLS握手失敗

• HTTPS頁面完全打不開

這時候需要檢查：

• SSL憑證是否過期

• 憑證綁定域名是否正確

• 中繼憑證是否完整

• CDN憑證是否已經更新

• 源站憑證是否正常

• TLS協定和加密套件配置是否相容

尤其是在更換伺服器、CDN或者重新簽發憑證後，比較容易出現源站已經更新，但 CDN 仍然使用舊憑證的情況。如果網站 HTTP 可以開啟，但 HTTPS 無法存取，通常就應該優先從這一層排查。

十、不同網站故障現象，應該先檢查什麼

實際排查時，沒有必要每一次都把所有項目全部查一遍。可以先根據現象確定優先級。

這樣排查最大的好處，就是不用每次都從伺服器開始查。

先根據故障表現判斷可能發生在哪一層，效率會高很多。

十一、網站偶爾打不開，最好開啟持續監控

還有一種故障比「完全打不開」更麻煩，就是網站偶發異常。比如：每天凌晨偶爾逾時幾分鐘，白天又完全正常；或者伺服器高負載時偶爾出現 502，但過一會兒自己恢復。這種問題靠人工開啟網頁測試，很難抓到真正的故障現場。等你發現使用者回報再去檢查時，網站可能早就恢復了。

這種情況下就需要使用 Chahu 網站監控持續觀察網站狀態。

除了普通 HTTP(S) 存取以外，還可以根據實際需求監控 Ping、TCP、DNS、SSL 等項目。

例如：

• HTTP突然無法存取

• DNS解析異常

• Ping延遲明顯升高

• TCP連接埠失聯

• SSL憑證出現問題

• 網站回應時間持續增加

透過歷史監控記錄，可以看到故障發生時間、持續時間以及恢復情況。

對於經常出現「使用者說打不開，但自己一測又正常」的網站來說，這類歷史資料往往比臨時測試更有價值。

十二、網站打不開的總體排查順序

如果不確定從哪裡開始，可以直接按照下面這套順序檢查：

網站打不開
    ↓
Chahu 多節點網站測速
    ↓
判斷是全國異常還是局部異常
    ↓
Ping 檢查網路連通性
    ↓
DNS 查詢確認解析 IP
    ↓
Traceroute 檢查網路路徑
    ↓
檢查 HTTP 狀態碼 / 80 / 443 連接埠
    ↓
檢查 CDN / WAF / SSL
    ↓
檢查源站 Web 服務和伺服器負載

這套方法的核心並不是使用多少工具，而是先判斷故障屬於哪一層。

網站打不開最麻煩的情況，往往不是故障本身有多複雜，而是一開始就排錯了方向：明明是某個電信商的線路問題，卻不停重啟伺服器；明明域名還解析到舊 IP，卻一直修改 Nginx；明明是 SSL 憑證過期，卻反覆檢查 CDN 節點，這些操作不僅浪費時間，還可能讓原本正常的配置變得更亂。

實際處理時，可以先利用 Chahu 的多節點網站測速確認故障範圍，再按照 Ping、DNS、路由、HTTP/HTTPS、CDN、源站 的順序逐層縮小範圍。只要先確定問題發生在哪一層，大多數「網站突然打不開」的故障，定位起來都會簡單很多。

相關問答

1. 瀏覽器顯示"無法存取此網站"和"連線已重設"，這兩種報錯指向的問題有什麼不同？

區別很大。"無法存取此網站"通常意味著TCP連線建立失敗，比如伺服器沒開443連接埠、防火牆攔截了請求、或者IP根本不可達，問題出在連線層面。"連線已重設"則意味著TCP握手已經成功了，但伺服器端主動把連線斷開了，這種情況常見於防火牆攔截、WAF觸發規則、或者伺服器內部主動拒絕了請求。實際排查中遇到"連線已重設"，我會優先檢查安全策略和WAF日誌，而不是去看連接埠通不通。

2. 伺服器CPU跑滿了會導致網站打不開嗎？具體現象是什麼？

會，而且現象很有特點。CPU滿載的時候，伺服器的TCP連線棧還在正常工作，所以Ping能通、TCP握手也能成功。但Web服務（比如Nginx或PHP-FPM）已經沒有CPU資源去處理請求了，瀏覽器會卡在"正在建立安全連線"或者"正在等待回應"的狀態，然後逾時傳回504或者直接報連線失敗。如果監控看到回應時間從幾十毫秒突然飆升到幾秒然後逾時，同時CPU使用率接近100%，那基本就是CPU瓶頸導致的，不是網路問題。

3. 網站部署了CDN之後出現部分地區打不開，但源站直接IP存取正常，問題出在哪？

這種情況問題基本鎖定在CDN這一層，源站本身是沒問題的。先檢查CDN控制台的節點狀態，看看那個區域是不是有節點故障公告。如果沒有，讓打不開的使用者做一下本地DNS重新整理，因為CDN的排程也是基於DNS的，可能是使用者本地還快取著舊節點IP。再排查一下CDN的防盜鏈配置、IP黑白名單和地區存取限制，有時候配置了"僅允許中國大陸存取"之類的策略，海外的使用者就打不開了。

4. 怎麼區分是網站被攻擊了還是單純的流量高峰導致打不開？

被攻擊和流量高峰的表現確實很像，都會導致伺服器負載飆升、回應變慢甚至逾時。但有幾個細節能區分：被攻擊的時候存取日誌裡會出現大量來自不同IP的異常請求，User-Agent亂七八糟或者乾脆沒有，而且請求的URL高度集中（比如只刷某一個介面）。正常流量高峰的話，存取日誌裡各頁面分佈相對均勻，使用者行為有規律。另外如果伺服器頻寬被佔滿但CPU不高，很可能是流量型攻擊；如果CPU和資料庫連線數爆了但頻寬正常，更可能是應用層攻擊或者單純的業務高峰。

5. 排查網站故障的時候，先看伺服器日誌還是先看監控資料？

順序很重要。我的習慣是先看監控資料、再看伺服器日誌。監控資料（比如Chahu的多節點探測結果）能幫你快速判斷故障範圍和影響面，是全國掛了還是只有某個地區掛了，這是排錯的第一步決策依據。有了方向之後再登入伺服器看Nginx access log和error log，找具體的錯誤線索。如果上來就登入伺服器翻日誌，很容易因為資訊量太大而迷失方向，而且如果問題出在CDN或者DNS層面，伺服器日誌裡根本不會有任何異常記錄，純屬浪費時間。