如何監控網站是否掛掉？網站在線狀態與即時告警方法

網站掛掉真正麻煩的地方，往往不是伺服器恢復需要多長時間，而是故障發生以後多久才有人發現。一個企業官網凌晨出現連線逾時，如果沒有持續監控，很可能第二天上班以後才被發現；電商網站的訂單介面回傳 500，首頁卻還能正常開啟，營運人員看到流量下降時才意識到下單流程已經中斷；還有一些故障更加隱蔽，比如：上海電信存取正常，廣州行動卻一直逾時，技術人員自己測試沒有問題，使用者端卻已經連續回報打不開。所以，「伺服器還在運行」並不能說明網站一定正常。

DNS 解析錯誤、CDN 節點異常、SSL 憑證問題、電信商線路故障、應用程式介面報錯，都可能讓使用者看到和伺服器掛掉非常相似的結果。想要儘早發現這些問題，不能等使用者回報，也不能偶爾手動開啟網站看一眼，而應該建立一套持續的網站在線狀態監控和即時告警機制。下面就從實際維運的角度，看看網站掛掉應該怎麼判斷、如何監控，以及出現異常以後應該按照什麼順序排查。

一、什麼情況才算網站掛掉？

很多人聽到「網站掛掉」，第一反應就是伺服器關機或者機房斷網。實際上，真實的網站故障要複雜得多。從使用者體驗來看，只要使用者無法正常完成存取或者關鍵操作，就已經屬於網站可用性異常，只是嚴重程度不同。

1. 整站完全無法存取

這是最典型的掛掉場景。例如監控請求網站時連續出現：

Connection Timeout
Connection Refused
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

而且不同地區、不同電信商的偵測節點都出現相同問題，就要重點檢查源站伺服器、負載平衡、CDN、機房網路以及應用程式服務。這種故障通常比較容易發現，因為影響範圍大，使用者回報也會非常集中。

2. 只有部分地區無法存取

這種問題反而更難查。例如同一個網站，在同一時間出現下面的結果：

從上海辦公室存取網站完全正常，但廣州行動使用者已經打不開。這種情況可能與電信商線路、DNS 排程、CDN 區域節點、BGP 路由甚至特定 IP 的網路可達性有關，並不能簡單歸結為「伺服器掛掉」。因此，網站在線狀態監控不能只有一個偵測位置。

3. 首頁線上，但核心業務已經不可用

還有一種容易被忽略的情況，就是網站看上去沒有掛掉。

例如：

首頁                  200 OK
商品詳情頁            200 OK
/api/login            200 OK
/api/order            500
/checkout             Timeout

如果監控系統只檢查首頁，它會一直顯示網站處於正常狀態。但對於電商網站來說，使用者已經無法下單；對於 SaaS 平台來說，如果登入或者核心 API 失效，實際上同樣屬於嚴重故障。所以判斷網站是否掛掉，不能只問「首頁能不能開啟」，還應該問：使用者最重要的業務流程還能不能正常完成？

二、網站掛掉是怎麼被監控到的？

網站在線監控的原理並不複雜。簡單來說，就是讓位於外部網路中的探測節點按照固定時間間隔主動存取網站，然後記錄每一次存取結果。

例如每隔一分鐘請求一次：

https://example.com/

正常情況下可能得到：

HTTP/1.1 200 OK
Response Time: 183ms

如果網站出現問題，則可能回傳：

HTTP/1.1 503 Service Unavailable

或者直接出現：

Connection Timeout

監控系統會持續記錄這些結果，一旦達到設定的異常條件，就觸發告警。

實際監控中通常會關注幾個基本訊號：

• 網站能否建立連線；

• HTTP/HTTPS 是否正常回傳；

• HTTP 狀態碼是否異常；

• 回應時間是否突然升高；

• DNS 是否能夠正常解析；

• SSL/TLS 握手是否正常；

• 頁面是否回傳預期內容；

• 核心 API 是否正常回應。

這裡有一個很重要的區別：一次存取失敗，不一定代表網站真的掛掉。公網本身就存在短暫丟包、路由抖動和節點異常，如果某個監控節點偶爾逾時一次就立即發送掛掉通知，很容易產生大量誤報。比較穩妥的方式是連續偵測並進行二次確認，例如：

第一次偵測失敗
        ↓
30秒後再次偵測
        ↓
仍然失敗
        ↓
其他節點同步驗證
        ↓
確認異常範圍
        ↓
觸發告警

這樣既能儘快發現故障，也能減少偶發網路抖動帶來的干擾。

三、為什麼不能只用一個節點監控網站？

網站伺服器只有一台，不代表使用者存取網站只有一條路徑。一個北京使用者存取部署在中國香港的網站，可能經過聯通骨幹網；廣州行動使用者存取同一個網站，則會經過完全不同的電信商網路和出口。使用 CDN 以後，請求甚至可能被排程到不同邊緣節點。

這就導致一種非常常見的現象：網站不是整體故障，而是某一條存取路徑出了問題。比如某次網站異常：

上海電信     82ms      正常
北京聯通     103ms     正常
成都電信     97ms      正常
廣州行動     Timeout   異常
深圳行動     Timeout   異常
香港         71ms      正常

如果你的監控伺服器剛好部署在上海，那麼整個故障期間監控後台可能始終顯示「Online」。

但對於廣州和深圳的一部分行動使用者來說，網站實際上已經處於不可用狀態。

因此，網站監控最好覆蓋真實使用者所在的主要地區，並儘量包含不同電信商。

國內業務尤其應該關注：中國電信、中國聯通、中國行動 + 主要省市節點。

如果同時做跨境業務，再加入中國香港、新加坡、日本、美國或其他主要市場節點，得到的結果會更接近真實使用者存取情況。

四、如何透過多節點判斷網站是否真正掛掉？

收到「網站打不開」的回報以後，第一件事不應該急著重啟伺服器，而是先確認故障範圍。

這一步可以透過Chahu多節點偵測快速完成。使用 Chahu 網站監控 從不同地區和電信商觀察網站狀態。Chahu 目前的網路偵測體系支援按中國電信、中國聯通、中國行動以及港澳台、海外節點進行查看。拿到多節點結果以後，一般可以按照下面幾種情況判斷。

情況一：絕大多數節點同時失敗

如果電信、聯通、行動以及海外節點都出現連線逾時或 5xx，網站整體故障的可能性就比較高。

這時應該重點檢查：伺服器是否正常運行、Web 服務是否啟動、CDN 是否正常回源、防火牆策略是否誤封、域名是否正常解析，以及機房網路有沒有異常。

情況二：只有某個電信商異常

這時千萬別急著給伺服器升級配置，根本不是效能的問題。重點去看行動的線路、DNS 排程以及行動方向的路由走得對不對。

情況三：只有某個地區異常

大概率是區域性的網路鏈路問題，或者這幾個節點被 CDN 異常排程到了同一台出故障的邊緣節點上。

情況四：網站能夠存取，但回應時間明顯異常

平時跑 100 毫秒的頁面，突然連續十幾分鐘要兩三秒才出得來，這就是掛掉前的預警訊號了。趕在徹底癱瘓前，趕緊去排查資料庫壓力、源站 CPU 負載還有網路頻寬。

五、網站即時告警應該怎麼設定？

監控要是只記日誌不發通知，那充其量就是一份冷冰冰的統計報表。真正管用的線上監控，得在問題露頭時主動拍拍維運的肩膀，搶在使用者大面積吐槽之前把故障撲滅。要讓告警真正發揮作用，這幾點很關鍵：

1. 不建議一次失敗立即報警

如果只要偶爾來個 Timeout 就狂發簡訊，久而久之維運耳朵都會聽出繭子，最後乾脆把通知靜音。合理的做法是設一個「緩衝機制」：根據業務重要程度來定連續失敗次數。比如普通官網可以設為連續失敗 2 到 3 次再報警；核心業務則可以把偵測間隔拉頻，同時用多個地區的節點交叉校驗，確認真的出了問題再發通知。

2. 不要只設定「網站離線」告警

實際維運裡，網站徹底打不開只是故障的終極形態，很多隱患在崩塌前就已經有徵兆了。除了基礎的通斷，這些指標同樣值得盯緊：

這裡要特別提一句：回應時間閾值千萬別搞一刀切。一個平時只要 150 毫秒的 API，突然飆到 1.5 秒，哪怕還沒逾時也絕對有問題；但換成一個需要複雜計算的報表頁面，耗時 2 秒可能完全正常。最穩妥的方法是先讓監控跑幾天，摸清各個介面的正常底細，再據此設定合理的警告線。

3. 告警必須按嚴重程度分級

並不是所有雞毛蒜皮的小事都值得大半夜把人叫醒。

比如 SSL 憑證還有 15 天到期，發個郵件或者釘釘群訊息打個招呼就行；某個邊緣節點短暫波動，記錄下來留作觀察即可；但要是多個核心節點同時連不上，就必須立刻觸發電話轟炸或簡訊的高優先級報警。

團隊內部也得把分工明確好，誰負責處理什麼級別的故障。不然哪天真正致命的問題夾在一堆日常雜音裡被無視了，那才是最大的災難。

六、網站掛掉後，應該按照什麼順序排查？

確認網站真的出了故障，最忌諱的就是像無頭蒼蠅一樣瞎撞，手忙腳亂地到處改設定。搞不好原本只是個小網路波動，結果自己一番亂操作把現場全破壞了。

最省心也最高效的排查思路，其實就是「由外向內」一層層剝洋蔥，逐步縮小嫌疑範圍。

第一步：先看受災範圍到底有多大 

收到打不開的回報，第一件事是用 Chahu 抓幾個不同地區和電信商的節點測一輪。先搞清楚：到底是整個網站死透了，還是只有一部分使用者存取受阻？

• 全國和海外節點全線淪陷： 基本上可以鎖定是源站、CDN 整體服務或 DNS 出了大問題。

• 只有特定地區或某家電信商打不開： 別急著動源站，優先盯緊電信商線路、DNS 排程以及 CDN 的邊緣節點。

這個問題搞清楚了，後面的排查才不會跑偏。

第二步：看看 HTTP 狀態碼吐出的是啥 

只要請求還能連上伺服器，就看看它回傳的是什麼錯誤代碼，這能幫你直接定位到故障層級：

• 502 Bad Gateway： 前端的代理（比如 Nginx 或 CDN）找不到後面的源站了，重點去查上游源站的服務程序還在不在。

• 503 Service Unavailable： 伺服器目前扛不住了，大概率是存取量暴漲過載、資料庫連線池乾了，或者是系統正在掛牌維護。

• 504 Gateway Timeout： 前端閘道把請求發過去了，但源站卡在裡面半天不回訊息，通常是資料庫死結或後端邏輯處理太慢。

• 直接 Connection Timeout（連線逾時）： 連狀態碼都拿不到，那就別看 Web 服務了，直奔防火牆策略、伺服器連接埠監聽和基礎網路去查。

3. 檢查 DNS 解析有沒有貓膩 

DNS 是排查時極容易被漏掉的一環。用 DNS 查詢工具跑一下，看看域名目前解析出來的 IP 對不對，不同地區拿到的結果是不是一致。

重點盯這幾樣：

• A/AAAA 記錄和 CNAME 是不是被誰誤改了；

• 是不是還解析在早該廢棄的老伺服器 IP 上；

• CDN 域名有沒有正常生效；

• 是不是只有某個電信商拿到了錯誤的解析結果。

舉個很常見的例子：網站剛剛切了 CDN，上海地區已經順暢跑在新節點上了，而華南某些地方的 DNS 還在死扣著舊 IP 快取，使用者側自然就會出現「有人能進、有人進不去」的怪現象。

4. 丟幾個 Ping 看看基礎連通性 

域名解析沒毛病，接著可以用 Chahu 的線上 Ping 測一下目標 IP 的延遲和丟包。

這裡有個大坑要注意：Ping 不通不等於網站掛了。很多伺服器和安全防火牆為了防掃描，會直接幹掉 ICMP 協定。Ping 的真正價值在於幫你觀察：

• 延遲有沒有突然出現幾倍的飆升；

• 某些地區是不是丟包丟到了不可接受的程度；

• 是不是只有行動或者聯通跑不過去。

如果 HTTP 請求逾時，同時多個節點的 Ping 也出現嚴重丟包或延遲暴漲，那就可以打包票是網路路徑出了狀況。

5. 上 Traceroute 或 MTR 扒路由 

一旦基本確定是網路層出的毛病，就該看看到底卡在哪個骨幹節點上了。

請求從使用者端發起到源站，走的線路大體是這樣的：使用者→本地電信商→省級骨幹網→跨網/國際出口→CDN邊緣節點→回源鏈路→源站

沿著鏈路一路追蹤下去，看看到底是在哪一步延遲突然飆到幾百毫秒，或者哪裡的節點開始大面積丟包。是電信商的跨網互聯堵死了，還是 CDN 回源的鏈路斷了，一扒便知。

相比一發現「打不開」就抓瞎去重啟伺服器，這種從外向內、層層剝離的排查法不僅速度快，而且絕不會因為誤操作帶來二次傷害。

七、為什麼不能只監控網站首頁？

很多剛接觸維運或建站的朋友，第一次設定監控時通常只丟進去一個首頁地址：https://example.com。

有監控當然比裸奔強，但對真正靠流量變現或承載業務的網站來說，只看首頁完全是掩耳盜鈴。

在實際維運中，下面這種情況太常見了：

https://example.com/ (首頁)            --> 200 OK (跑得飛快)
https://example.com/item/123 (詳情頁)  --> 200 OK (完全正常)
https://example.com/user/login (登入)  --> 200 OK (毫無問題)
https://example.com/api/order (下單)   --> 500 Internal Error (後端報錯)
https://example.com/checkout (結算)    --> Timeout (直接卡死)

這時候你的監控面板可能還是一片喜慶的綠燈，但真正決定公司現金流的下單和支付流程早就癱瘓了。使用者買不了東西，抱怨聲四起，你卻還在以為網站運行得好好的。

所以，設定監控的核心原則只有一條：盯著「使用者必須完成的關鍵動作」去測，而不是只看門面。

不同類型的網站，側重點完全不同：

• 企業官網： 重點盯緊首頁、核心落地頁（Landing Page）、域名 DNS 解析以及 SSL 憑證過期時間。

• 電商平台： 除了首頁和商品頁，登入、購物車、下單 API 以及結算頁面必須全流程覆蓋。

• SaaS 平台： 重點關注/login頁面、核心業務 API、/api/health健康檢查、WebSocket 長連線，以及後台的任務排程佇列。

• API 服務： 絕對不能只看連接埠通不通。必須校驗介面回傳的 HTTP 狀態碼、回應時間，甚至檢查回傳的 JSON 資料結構是不是預期內容。

有些服務設定了/api/health介面，它不管資料庫死活，只要 Nginx 活著就固定回傳200 OK。這種虛假的「健康」毫無意義，一旦底層資料庫或快取掛了，業務介面早已報錯，簡單的線上偵測卻依然以為一切正常。把這些關鍵鏈路一處處盯緊，才能在真正影響業務時第一時間收到通知。

八、網站監控多久偵測一次比較合適？

頻繁程度取決於這個網站掉線一分鐘，你會損失多少錢。

• 個人部落格、普通展示型官網： 1 到 5 分鐘測一次足夠了，沒必要折騰。

• 電商、SaaS 平台、線上業務系統： 建議拉到 30 秒到 1 分鐘測一次。

• 支付服務、核心金融 API： 需要高頻外部監控，並且必須配合伺服器內部的指標（CPU、記憶體、日誌）一起盯。

不過也別盲目追求「10 秒測一次」。如果你的監控節點只有一個，頻率設得再高，只要那個節點自身的網路抖一下，就會給你狂發誤報。真正可靠的監控體系，永遠是：合理的偵測頻率 + 多個節點交叉驗證 + 連續失敗再觸發 + 按嚴重程度分級通知。這套組合拳打下來，比單純在頻率數字上卷高低有用得多。

監控網站是否掛掉，真正需要解決的不是「偶爾開啟網頁看一下」，而是建立一套持續的外部偵測機制，在故障真正影響大量使用者之前發現異常。對於普通網站來說，HTTP 狀態、回應時間和核心頁面已經是最基礎的監控內容；如果使用 CDN、海外伺服器或者使用者分佈在多個地區，就不能只依賴單一節點，還應該觀察不同電信商和不同地區的存取結果。

日常巡檢或者發現異常時，可以透過 Chahu 網站監控 從不同地區觀察網站在線狀態。如果發現只有部分節點異常，再結合 DNS、Ping 和路由資訊繼續往下排查，通常能夠更快區分到底是伺服器故障、CDN 排程問題，還是某條電信商線路出現異常。網站監控的目的從來不是多看幾個數字，而是盡可能把「使用者回報網站打不開」變成「使用者還沒發現，我們已經開始處理」。這才是持續監控真正能帶來的價值。

相關問答

1. 網站在本地存取正常，但監控提示 502 Bad Gateway 是什麼原因？

這通常是 Nginx、反向代理或 CDN 與源站伺服器通訊失敗導致的。本地存取正常可能是因為你連線的是特定節點或走的是內部網路，而外部監控請求到了異常的反向代理節點。遇到這種情況，優先排查源站應用程式程序（如 PHP-FPM、Node.js 實例）是否在瞬時高並發下掛掉，或者閘道層設定的proxy_read_timeout逾時時間過短。

2. 為什麼有時公網只有某個特定電信商打不開網站？

這種情況多半不是伺服器關機，而是網路傳輸鏈路發生了故障。常見原因包括：DNS 智慧解析向該電信商分配了失效的 IP；特定電信商的跨網骨幹網出口發生壅塞或路由繞行；或者 CDN 在該電信商部署的邊緣節點掛掉。可以用Chahu單獨篩選該電信商的節點進行 Ping 和 MTR 跟蹤，找出報文丟失的具體骨幹網路由段。

3. SSL 憑證故障會導致監控系統判定網站掛掉嗎？

會。大部分嚴謹的 HTTP(S) 監控節點在遇到 SSL/TLS 握手失敗、憑證過期、域名與憑證不匹配或中間憑證鏈缺失時，會直接終止 TCP 連線並標記為錯誤（如SSL Handshake Failed）。為了防止因為憑證過期導致網站突發無法存取，建議將 SSL 憑證剩餘有效天數（如小於 15 天）單獨列為中風險預警項目。

4. 收到網站掛掉通知後，排查故障的第一步應該做什麼？

不要盲目重啟伺服器。第一步是確認故障影響範圍：使用多節點監測工具看一下是全國大面積掛掉，還是單地區/單電信商故障。第二步看錯誤狀態碼：如果是502/504找反向代理與源站通訊；如果是DNS Lookup Failed檢查域名解析與域名商；如果是Connection Timeout則優先排查源站防火牆、安全群組策略或機房網路斷連。

5. 既然已經有伺服器內部監控（如 CPU、記憶體監控），為什麼還需要外部網站監控？

因為內部監控存在「視角盲區」。伺服器 CPU 佔用率 10% 只能說明硬體資源充裕，但如果公網 DNS 解析被篡改、CDN 節點故障、SSL 憑證過期或者電信商骨幹網路由中斷，內部監控完全感知不到。外部監控是以真實使用者存取路徑為視角進行探測，能直接反映最終的使用者體驗。