網站存取逾時怎麼檢測？回應慢與連線失敗排查方法

網站打開很慢、頁面一直轉圈，最後提示連線逾時，看起來都是「網站存取出了問題」，但實際原因可能完全不同：有時候是域名解析遲遲沒有結果，有時候是伺服器連接埠根本連不上，也有一種情況是連線已經建立，只是源站、資料庫或者後端介面遲遲沒有回傳內容。表面上都是「打不開」，故障位置卻可能相差好幾層。

遇到網站存取逾時，不能只靠反覆重新整理頁面或盲目重啟伺服器。更高效的方法是先弄清楚請求卡在了哪個階段，再根據具體的檢測資料逐層排查。本文將從網站回應慢、連線失敗和存取逾時這幾種常見現象入手，梳理一套清晰實用的維運排查思路。

一、網站存取逾時、回應慢和連線失敗有什麼區別？

很多剛接觸維運的站長容易把「逾時」、「回應慢」和「連線失敗」混為一談。但在排查故障時，這三者對應的技術環節截然不同。你可以參考下表快速區分它們的特徵：

1. 存取逾時

通常表現為請求發出後長時間沒有完成，瀏覽器一直處於載入狀態，最終彈出一個逾時錯誤；或者表現為「偶爾能打開，偶爾打不開」。這種問題通常發生在傳輸層網路路由卡頓、CDN 回源逾時或應用層處理耗時過長。

2. 回應慢

這說明 TCP 連線和 HTTP 請求都已經順利到達了伺服器，網路基礎通路是沒問題的。瓶頸在於 Web 服務（如 Nginx/Apache）處理緩慢、後端程式（如 PHP/Java/Node.js）執行效率低、資料庫出現慢查詢，或者頁面呼叫的第三方介面拖慢了整體渲染速度。

3. 連線失敗

這類問題的排查位置比前兩者更靠前。如果出現連線失敗，說明用戶端連目標伺服器的 TCP 門檻都沒跨過去。常見原因包括伺服器 80/443 連接埠未開放、系統防火牆攔截了用戶端 IP、Web 程序掛掉未監聽連接埠，或者路由路徑徹底中斷。

二、網站逾時先從哪一步開始檢查？

一次正常的網站存取，中間實際上要經過多個環節：

DNS解析 → 網路連線 → TCP建立 → TLS握手 → HTTP請求 → 應用處理 → 頁面回傳

其中任何一步長時間沒有完成，都可能表現成網站載入慢或者存取逾時。

因此，排查時沒必要一開始就進入伺服器後台翻日誌。

更實用的順序是先從外部存取鏈路開始：

1. 看域名能不能正常解析；

2. 看基礎網路有沒有明顯異常；

3. 看HTTP請求能不能正常得到回應；

4. 對比不同地區、不同電信業者的結果；

5. 再檢查HTTPS、源站和應用。

這種順序的好處是，可以先判斷問題究竟出在「網站外面」還是「網站裡面」。

三、網站存取逾時時的具體排查步驟

第一步：檢查DNS解析是否正常

排查故障的第一步，是確認域名是否能被正確解析為 IP 位址。

在命令列輸入nslookup或dig，或者直接借助線上DNS查詢工具進行全網解析排查。在這個階段，重點觀察以下幾點：

• 域名能否正常解析出 IP；

• 全國各省份節點的解析結果是否一致；

• 解析出來的 IP 是否屬於當前正在使用的伺服器或 CDN 節點；

• CDN 的 CNAME 記錄是否生效且正常指向。

DNS 異常時的典型表現

1. 在瀏覽器輸入網址後，左下角長時間顯示「正在正在尋找主機...」或「正在解析域名」；

2. 部分地區的使用者反映網站完全打不開，而其他地區正常；

3. 使用者切換手機熱點或更換公共 DNS（如 223.5.5.5 / 114.114.114.114）後，網站立刻能正常存取；

4. 直接使用 IP 位址可以存取（在支援直接 IP 存取的場景下），但帶域名存取就逾時。

直接用 IP 存取網站並不總是能作為判斷依據。因為在啟用 HTTPS 憑證、設定了 HTTP/2、虛擬主機或綁定了特定 Host 標頭資訊的現代 Web 架構中，直接存取 IP 往往會回傳 403、400 錯誤或憑證域名不符警告，這屬於正常現象。

第二步：用Ping判斷網路連線有沒有明顯異常

排除 DNS 問題後，需要測試用戶端到伺服器或CDN 節點的底層 ICMP 網路連通性。直接用Chahu線上Ping 檢測工具發起全國多線路測試，重點關注：

• 是否存在高比例封包遺失；

• 是否出現大量節點 Request Timed Out（請求逾時）；

• 是否僅有特定電信業者（如移動、電信、聯通）出現異常；

• 平均網路延遲是否突然大幅飆升。

Ping 不通不代表網站一定打不開。現代很多 Web 伺服器、高防 IP 或 CDN 節點為了防範網路掃描和 DDoS 攻擊，會在防火牆或安全群組中明確停用 ICMP 協定（禁 Ping）。如果 Ping 全無回應但 HTTP 狀態正常，這屬於正常的安全策略。

Ping 檢測的判定邏輯

• 大部分節點 Ping 延遲低且無封包遺失：說明基礎網路骨幹鏈路通暢，可以排除廣域網路大面積路由中斷，應立刻前往下一步檢查 HTTP/Web 服務。

• 只有部分地區或單一電信業者出現逾時：重點排查跨網互連品質、地區骨幹網波動、CDN 在該地區的邊緣節點故障，或是 DNS 地域調度策略設定有誤。

• 全國大量節點普遍封包遺失或逾時：大概率是源站公網 IP 被封鎖、源站機房線路故障、高防/CDN 回源鏈路中斷，或者上游 ISP 骨幹網發生割接。

第三步：檢查HTTP回應和502、503、504

如果網路層面能夠連通，下一步就要探明 HTTP/HTTPS 請求是否真正觸達了 Web 服務層。

透過HTTP 狀態檢測發起請求，觀察伺服器回傳的 HTTP 狀態碼以及 Response Header。重點不是解讀狀態碼的字面意思，而是判斷請求究竟停在了哪一層：

1. 回傳 200 OK，但頁面載入依然緩慢

這說明 Web 伺服器已經成功接收並處理了請求，底層管道是暢通的。瓶頸多半在於靜態資源（圖片、CSS、JS）體積過大、後端動態 API 渲染拖沓，或者是頁面載入了不可達的第三方外鏈指令碼。

2. 回傳 502 Bad Gateway（錯誤閘道）

常見於反向代理架構（如 Nginx + PHP-FPM / Node.js / Java Tomcat）。這表示前端代理伺服器（Nginx）正常運作，但它無法與後端的應用服務建立連線，或者後端程式崩潰掛掉了。

3. 回傳 503 Service Unavailable（服務無法使用）

通常意味著 Web 伺服器本身處於超載狀態，或者觸發了連線數限制、防 CC 攻擊策略規則，導致伺服器拒絕處理新的連線。

4. 回傳 504 Gateway Timeout（閘道逾時）

這是與「存取逾時」最緊密相關的狀態碼。504 明確表示 Nginx 等代理伺服器（或 CDN 節點）已經把請求轉交給了源站/後端應用，但在規定的等待時間內，後端應用遲遲沒有回傳處理結果。

導致 504 逾時的常見根源包括：

• 後端資料庫出現鎖表或耗時極長的全表掃描慢查詢；

• 應用程式碼在同步等待外部第三方 API 回傳，而該 API 回應卡死；

• PHP-FPM 處理程序池滿載或 Java Worker 執行緒全部被阻塞；

• CDN 回源到源站伺服器的逾時時間（Origin Timeout）設定過短。

第四步：判斷是「連線慢」還是「伺服器回應慢」

當確定網站存在耗時問題後，需要把「慢」字拆解開來。連線階段慢和回應階段慢，對應的優化方向完全相反：

用戶端請求 ──(1. DNS/TCP/TLS)──> 伺服器端接收 ──(2. 應用處理/資料庫)──> 資料回傳
           └─── 連線階段慢 ───┘                └─── 回應階段慢 ────┘

1.連線階段耗時極高（TTFB 前段卡頓）

如果在開發者工具（F12）的網路面板中，看到 Initial Connection 或 SSL/TLS Handshake時間極長：

• 核心原因：DNS 解析慢、用戶端與伺服器距離過遠導致 RTT 延遲高、TCP 三次握手封包遺失重傳，或是伺服器 TLS 握手計算開銷大（如單核 CPU 滿載導致密碼學計算受阻）。

2.連線瞬間完成，但 Waiting for server response (TTFB) 極長

在網路面板中，TCP 握手只需幾十毫秒，但 Waiting (TTFB - 首位元組時間) 卻要持續數秒甚至數十秒：

• 核心原因：網路通道完全沒問題，純粹是伺服器後端「出汗了」。需要立刻深入源站內部，檢查 Web 應用邏輯、資料庫索引、Redis 快取命中率以及 CPU/記憶體/磁碟 I/O 資源佔用。

3.HTML 頁面首位元組回傳很快，但瀏覽器分頁一直在轉圈

• 核心原因：HTML 主文件載入順利，但頁面中非同步載入的某個 Ajax/Fetch 介面卡死，或者引用的第三方分析統計程式碼、CDN 託管指令碼逾時未能載入完畢，阻塞了瀏覽器的onload事件。

第五步：檢查是不是只有部分地區或電信業者逾時

在複雜的廣域網路環境下，很多逾時故障具有「局部性」。用chahu全國三網多節點網站測速對比不同地區和電信業者的測試資料，可以快速定位故障範圍：

• 僅某個省份或城市節點逾時：通常是該地區的骨幹網線路出現突發波動、當地 ISP 電信業者路由封包遺失，或者 CDN 分配給該地區的邊緣節點出現了服務異常。

• 僅某一家電信業者（如跨網移動存取電信源站）逾時：典型的跨網互連品質問題。如果源站是單線機房（例如純電信線路），移動使用者跨網存取時很容易出現路由繞路和高封包遺失。

• 全國各地區、三大電信業者無一例外全部逾時：問題集中在源站本身（伺服器當機、機房斷網、叢集掛掉）、全域 CDN 故障或頂級 DNS 服務失效。

第六步：HTTP 正常，但 HTTPS 連線失敗怎麼辦？

在很多實際場景中，站長會發現 HTTP 存取（80 連接埠）秒開，但換成 HTTPS（443 連接埠）後頁面就陷入無止盡的轉圈，最終提示連線失敗。

出現這種情況時，重點排查 SSL/TLS 層面的設定：

1. 憑證有效性與域名匹配：檢查 SSL 憑證是否過期，或者憑證綁定的域名是否包含當前存取的子域名；

2. 443 安全群組與防火牆：確認伺服器防火牆（如 iptables/firewalld）以及雲端廠商的安全群組規則中，是否只開放了 80 連接埠而遺漏了 443 連接埠；

3. TLS 協定與加密套件相容性：伺服器是否停用了過時的 TLS 1.0/1.1，同時用戶端（如老舊裝置/舊版瀏覽器）又不支援 TLS 1.2/1.3；

4. SNI（伺服器名稱指示）設定：在一台伺服器綁定多個 HTTPS 站點時，Web 伺服器（Nginx）是否正確設定了 SNI 映射；

5. CDN 邊緣與源站憑證設定：如果使用了 CDN，需確認「用戶端到 CDN」以及「CDN 回源到源站」兩段的 HTTPS 策略是否匹配（例如源站未設定憑證，但 CDN 開啟了全程強制 HTTPS 回源）。

四、網站回應慢，常見原因有哪些？

如果網站最終能夠打開，只是回應時間明顯變長，常見原因通常集中在下面幾個方面。

1. 伺服器負載過高

CPU持續滿載、記憶體不足、連線數過多，都可能讓請求排隊等待。

這種情況在存取高峰期尤其明顯。

2. 資料庫查詢過慢

動態網站的很多頁面都依賴資料庫。

如果SQL查詢效率低、資料量突然增大或者資料庫連線不足，前端看到的結果往往就是頁面遲遲沒有回傳。

3. CDN回源時間過長

使用CDN並不代表所有請求都直接從邊緣節點回傳。

快取沒有命中、動態頁面或者API請求仍然可能回到源站。

如果源站本身回應慢，CDN等待回源的時間也會變長。

4. 網路線路不穩定

網路延遲過高、持續封包遺失或者路由異常，都可能拉長連線和資料傳輸時間。

如果問題只集中在某些地區，更應該考慮線路因素。

5. 第三方介面回應慢

支付、登入、簡訊、驗證碼、地圖、統計等外部介面，都可能成為頁面等待的原因。

主站伺服器正常，並不代表依賴的第三方服務也正常。

6. 程式執行時間過長

複雜計算、大量同步任務、低效率程式碼或者介面迴圈呼叫，都可能讓請求遲遲沒有回傳。

這類問題通常需要結合應用日誌進一步定位。

五、 快速診斷決策表

當接到網站存取逾時的報警時，可以對照下表快速確定第一排查現場：

排查網站逾時和卡頓，最忌諱的就是在沒有資料支撐的情況下「盲目改設定」。下次再遇到網頁轉圈或提示 Timeout，不妨先把伺服器日誌和終端測試工具跑一遍，把範圍縮小到具體的環節，再去動程式碼或伺服器設定。

另外在日常維護中，建議大家可以在chuhu將網站加上網站監控，這樣在使用者發現故障之前，你就會先收到網站監控告警。很多時候，等到使用者來回報「打不開」時，故障往往已經持續很久了。建立起完善的健康檢查機制，在回應時間異常飆升時就及時干預，才是保障網站高可用的根本辦法。

相關問答

1. 網站用了長連線，逾時和 Keep-Alive 有關係嗎？
有。Keep-Alive 復用連線能省握手，但閒置連線太多會佔滿 worker 連線數，新請求排隊。Nginx 的 keepalive_timeout、upstream keepalive、後端連線池都要看。如果逾時集中在高峰，先查連線復用和池子大小。

2. HTTP/2 或 HTTP/3 下逾時怎麼排查？
HTTP/2 多路復用，一個流卡住不一定全卡，但連線級視窗、流控、伺服器並行限制都會影響。HTTP/3 走 UDP，封包遺失和 MTU 更敏感。先看瀏覽器協定列，再對比 HTTP/1.1 是否正常，能快速判斷是不是協定層問題。

3. 負載平衡健康檢查正常，使用者還是逾時，為什麼？
健康檢查通常只測一個簡單頁面或連接埠，後端真慢、某個介面逾時、資料庫鎖住，它未必發現。看健康檢查路徑和閾值，再看真實業務日誌。如果健康檢查走內網、使用者走公網，也可能入口到 LB 這段有問題。

4. 日誌裡怎麼區分用戶端取消和伺服器端逾時？
Nginx 裡 499 一般是用戶端等不及斷開，504 是閘道等上游逾時。後端日誌如果看到 Broken pipe、context canceled，多半是用戶端走了。別把 499 當成伺服器故障，先看使用者網路和前端逾時設定。

5. 伺服器頻寬跑滿導致逾時，怎麼確認？
看監控裡出頻寬是否頂到上限，再看 TCP 重傳、封包遺失和佇列。頻寬滿時新建連線慢、下載卡，但小 API 可能還通。用 iftop/nload 看即時流量，結合雲端監控。別只盯 CPU，頻寬和連線數也會卡死。