如何 Ping 一個網站？網站連線測試完整教學

做網站維護時，經常會遇到一種很難憑感覺判斷的問題：網站打不開，到底是使用者自己的網路有問題，還是 DNS、伺服器、CDN 或電信業者線路出了故障？如果每次都直接從伺服器日誌或者程式設定開始排查，效率會非常低。很多時候，只要先做一次基礎網路測試，就能迅速排除一部分可能性。比如 Ping 網站網域，可以先確認網域是否能夠正常解析、目前網路是否能夠到達目標位址，以及有沒有明顯的逾時和封包遺失。

但網站連線性檢查並不是「Ping 一下」就結束了。本文會從實際排障角度介紹如何 Ping 一個網站，並結合 Ping IP、DNS 查詢、TCPing 和 HTTP/HTTPS 測試，梳理一套比較完整的網站連線性檢查方法。

一、為什麼網站打不開時可以先 Ping？

Ping 的價值在於快，輸入一個網域，幾秒鐘之內基本就能知道目前電腦與目標網站之間有沒有基礎網路通訊。如果連網域都無法解析，問題很可能還停留在 DNS；如果網域能夠解析，但請求全部逾時，就可以繼續從網路線路、防火牆和 ICMP 策略幾個方向檢查。

一個完整的網站存取過程其實比 Ping 複雜得多：

輸入網域
   ↓
DNS 解析
   ↓
建立網路連線
   ↓
TCP 連線
   ↓
TLS 握手
   ↓
HTTP / HTTPS 請求
   ↓
Web 伺服器處理
   ↓
回傳網頁內容

Ping 主要幫助我們檢查前面比較基礎的網路環節，所以它更像是網站故障排查的第一步，而不是最終結論。

二、如何 Ping 一個網站？

實際測試一個網站時，我一般會用兩種方法：本地 Ping 和線上 Ping。

如果只是想確認「我現在這台電腦到網站是否正常」，直接使用系統內建的 Ping 指令最快；如果要判斷全國不同地區、電信聯通移動，或者海外網路存取網站時是否正常，就更適合使用線上多節點 Ping。

1. 使用電腦內建的 Ping 指令

Windows 使用者可以按下：

Win + R

輸入：

cmd

開啟命令提示字元後執行：

ping example.com

如果網站能夠正常解析並回應，結果通常類似：

Pinging example.com [203.0.113.10] with 32 bytes of data:

Reply from 203.0.113.10: bytes=32 time=28ms TTL=52
Reply from 203.0.113.10: bytes=32 time=27ms TTL=52
Reply from 203.0.113.10: bytes=32 time=29ms TTL=52
Reply from 203.0.113.10: bytes=32 time=28ms TTL=52

Packets: Sent = 4, Received = 4, Lost = 0

如果已經知道伺服器 IP，也可以直接測試：

ping 203.0.113.10

直接 Ping IP 在排查 DNS 問題時特別有用，後面會具體講到。

macOS 和 Linux 的操作也差不多，開啟終端機後輸入：

ping example.com

很多 macOS 和 Linux 環境預設會持續發送 Ping，可以按：

Ctrl + C

停止測試。

本地 Ping 最大的優勢就是快。幾秒鐘就可以判斷：

我的電腦
   ↓
目前網路
   ↓
目標網站

這一條線路有沒有明顯異常。

但它的問題也很明顯：你只能測到自己這一條網路。

2. 使用線上 Ping 測試

如果你是網站管理員，只知道自己這裡 Ping 正常通常是不夠的。

比如你人在上海，使用電信寬頻，本地測試：

上海電信 → 網站：26ms

這個結果最多只能證明上海電信到目標網站暫時沒有明顯問題。北京聯通怎麼樣？廣州移動能不能存取？成都電信有沒有封包遺失？海外使用者是不是正常？這些情況僅靠自己電腦上的一次 Ping 看不到。這時候就可以直接使用Chahu線上多節點 Ping。

進入頁面後輸入網站網域或 IP 就可以開始檢測。目前 Chahu 支援單次測試和持續測試，也可以分別查看中國電信、中國聯通、中國移動以及港澳台、海外節點的結果，同時會顯示各節點的回應 IP、回應時間，以及不同區域的最快、最慢和平均延遲。

這種測試方式真正有價值的地方，是可以把不同地區的結果放在一起比較。

比如：

如果只在上海電信本地測試，你看到的可能只是：

25ms
正常

但把多個節點放在一起之後，就會發現問題明顯集中在移動線路。這時候後面的排查方向就不一樣了。你不需要一上來懷疑整台伺服器，而應該優先檢查移動電信業者線路、跨網互聯或者 CDN 對移動使用者的節點調度。兩種測試並不存在誰替代誰的問題。

實際排障時，通常可以先在本地快速測試一次。如果本地沒有發現明顯問題，但使用者仍然回報存取異常，再用多節點 Ping 擴大測試範圍。

三、Ping 一個網站後，結果應該怎麼看？

Ping 完以後，不建議只看一個time=xx ms。

判斷網站連線性時，我一般按照四個順序看：

有沒有解析出 IP → 有沒有收到 Reply → 延遲是否異常 → 有沒有封包遺失。

1. 先看網域有沒有解析出 IP

正常情況下會看到：

Pinging example.com [203.0.113.10]

說明：

example.com
   ↓
203.0.113.10

DNS 至少完成了這一次解析。

如果看到：

Ping request could not find host example.com

這時候問題很可能還沒有到網路線路這一層。優先檢查：網域有沒有輸入錯誤；A 或 AAAA 記錄是否存在；本地 DNS 是否正常；網域解析是否剛修改過；DNS 設定是否發生異常。這種情況下反覆測試 Ping 延遲沒有太大意義，因為系統連目標 IP 都還沒有拿到。

2. 看有沒有收到 Reply

正常情況一般是：

Reply from 203.0.113.10

說明目前網路能夠收到目標 IP 回傳的 ICMP 回應。

如果連續出現：

Request timed out.
Request timed out.
Request timed out.

則說明這幾次測試沒有收到 Ping 回覆。

但這裡很容易出現一個誤區：Ping 逾時不能直接等同於伺服器當機。有些雲端伺服器、防火牆、IDC 或 CDN 會主動限制 ICMP。即使 Ping 完全沒有回應，網站的 TCP 80 和 443 連接埠仍然可能正常工作。所以看到 Ping 逾時時，只能說明「沒有收到 ICMP 回覆」，不能直接寫成「網站已經無法存取」。

3. 看延遲有沒有明顯異常

比如：time=28ms 。表示這一次封包完成往返大約用了 28ms。

判斷延遲時，不建議機械套用「低於 50ms 就一定正常」這種標準。

比如：上海使用者 → 上海伺服器

和：上海使用者 → 美國伺服器

本身就不應該要求相同的 RTT。

實際排查時，我更關注的是同類節點之間有沒有明顯異常值。

比如：

北京電信    32ms
上海電信    29ms
南京電信    35ms
廣州電信    172ms

這種情況下廣州明顯偏離其他電信節點，就值得繼續檢查。

4. 看有沒有封包遺失

Windows 測試完成後通常會顯示：

Packets: Sent = 4, Received = 4, Lost = 0

也就是：

發送：4
收到：4
遺失：0

這一輪沒有發現封包遺失。

如果變成：

Sent = 20
Received = 18
Lost = 2

說明測試期間至少出現了兩次封包沒有正常回傳。不過，偶爾一次逾時和持續性封包遺失不是一回事。如果懷疑網站線路存在間歇性問題，最好延長測試時間或者使用持續 Ping，再看看封包遺失是不是反覆出現。

四、Ping 正常，為什麼網站還是打不開？

很多人測到Reply from 203.0.113.10 time=25ms，看到延遲又低又穩定，就覺得網路和伺服器肯定都沒問題。但一轉頭開啟瀏覽器，頁面卻死活載入不出來，直接彈出一句「無法存取此網站」。

出現這種落差，原因其實很簡單：Ping 通只能證明網路「路是通的」，不代表服務「開門營業了」。

Ping 使用的是 ICMP 協定，本質上只是在測試你和目標伺服器之間最底層的網路封包能不能往返。但你用瀏覽器存取一個 HTTPS 網站，背後需要走完一整套極其複雜的流程：

TCP 443 連接埠建立連線
   ↓
TLS 安全握手
   ↓
發送 HTTPS 請求
   ↓
Web 伺服器與後端處理
   ↓
回傳網頁資料

這中間只要任何一個環節掉鏈子，網頁就會直接卡死，而 Ping 卻依然可以跑得高高興興。具體來說，問題通常出在下面這幾個地方：

1. 80 或 443 連接埠被牆或沒開 

伺服器網路通暢（ICMP 正常），但伺服器本機防火牆、雲端廠商安全群組或者機房前置設備把 80/443 連接埠給堵死了。這時候底層網路能回應，但 Web 連線根本進不去。

2. Web 服務掛了或者卡死 

伺服器系統本身好端端的沒有當機，所以 ICMP 回應非常快。但後端的 Nginx、Apache、Node.js 或者 IIS 服務可能已經崩潰了，甚至行程直接不存在。沒有服務在監聽連接埠，網頁自然打不開。

3. CDN 邊緣節點通了，但來源站崩了 

如果網站套了 CDN，你 Ping 出來的位址大概率是 CDN 的邊緣節點，而不是真實的伺服器 IP。邊緣節點回應你只需要 20ms，Ping 起來體驗極佳；但當它去向你的來源站伺服器拿資料（回源）時，如果來源站連不上或者報錯，使用者在前端看到的依然是 502 Bad Gateway、504 Gateway Timeout 或者直接逾時。

4. TLS 憑證或應用層徹底報錯 

即使 TCP 連線建立成功了，如果在 TLS 握手階段因為憑證過期、網域不匹配而中斷，或者後端的 PHP/Java 報錯、資料庫死鎖、反向代理設定寫錯，請求都會在此終止。

所以，排查網站故障時，一旦發現 Ping 是通的，就千萬別再浪費時間去重複 Ping 幾十次了。這時候網路層已經完成了它的使命，你應該立刻把排查重點轉向 TCP 連接埠測試（TCPing）、TLS 握手情況以及 Web 服務的運行狀態。

五、網站 Ping 不通，應該怎麼繼續排查？

如果 Ping 不通，我通常不會馬上登入伺服器重啟服務，而是先判斷問題究竟在哪一層。

可以按照這個順序檢查：

Ping 網域
   ↓
能否解析出 IP？
   │
   ├─ 不能
   │    ↓
   │   檢查 DNS
   │
   └─ 能
        ↓
有沒有 Ping 回應？
        │
        ├─ 有
        │   ↓
        │  檢查 TCP / HTTP
        │
        └─ 沒有
            ↓
         直接 Ping IP
            ↓
         多節點測試
            ↓
      判斷本機還是線路問題

比如：

ping example.com

失敗，但是已經知道伺服器位址是：

203.0.113.10

可以繼續執行：

ping 203.0.113.10

如果 IP 能通，而網域不行，DNS 就是更值得檢查的方向。

如果直接 Ping IP 也不通，再看是不是只有自己這裡出現問題。

假設多節點測試結果是：

北京電信      正常
上海聯通      正常
廣州移動      正常
你的網路      逾時

這時候伺服器本身大概率不是第一排查對象，本機網路或者當前電信業者線路反而更值得檢查。

如果多個地區、多個電信業者都同時出現異常，再去檢查伺服器網路、IDC、CDN 和防火牆會更加合理。

六、為什麼你這裡 Ping 正常，其他使用者還是可能打不開？

這也是為什麼站長不能只依賴自己電腦測試。

假設網站部署完成以後，你在辦公室執行：

ping example.com

結果一直保持：

25ms
26ms
24ms
27ms

看起來非常穩定，但使用者回饋可能完全不同：

北京電信      正常
上海聯通      正常
成都電信      正常
廣州移動      高延遲
深圳移動      間歇逾時

這種情況通常說明問題不是「整個網站都不可用」，而是更可能集中在某個電信業者或者某段網路路徑。

比較常見的原因包括：

• 跨電信業者互聯擁塞；

• BGP 路由發生變化；

• CDN 節點調度到了較遠地區；

• 某個電信業者到當前機房線路品質較差；

• 某一區域出口出現異常。

多地區 Ping 的價值就在這裡：不是為了得到更多數字，而是為了確定故障範圍。

只要先確認問題集中在哪些地區，後續排查通常都會快很多。

七、Ping 網域和 Ping IP 有什麼區別？

很多剛接觸維運或建站的朋友，很容易把這兩種測試劃等號，覺得反正最後測的都是那台伺服器。

但實際上，這兩個操作在底層走過的路徑完全不一樣。

當你輸入ping example.com時，系統後台其實悄悄多跑了幾個步驟：

輸入網域 (example.com)
   ↓
詢問 DNS 伺服器（解析 IP）
   ↓
拿到真實/目標 IP (203.0.113.10)
   ↓
對該 IP 發起 ICMP 測試

而如果你直接輸入ping 203.0.113.10，系統就會完全跳過 DNS 詢問環節，直接拿著 IP 去敲門。

正因為它們一個走了 DNS、一個沒走，把這兩個測試結合起來用，反而是定位問題最快的小訣竅：

• Ping 網域失敗，但直接 Ping IP 正常： 這說明你的網路到伺服器本身沒任何問題，故障百分之百出在 DNS 環節。要嘛是網域解析沒生效、TTL 還沒過，要嘛是本機 DNS 快取污染或 DNS 服務商當機。

• 網域能解析出 IP，但 Ping IP 依然逾時： 這說明 DNS 已經順利工作了，問題出在更後面的網路層。這時候應該把排查方向轉向路由器線路、機房防火牆限制，或者伺服器本身禁 Ping。

另外還有一種極其常見的情況：Ping 出來的 IP，和你自己伺服器的真實 IP 對不上。很多人一看到這個就慌了，以為網域被劫持了。其實這大概率是正常的，只要網站接入了 CDN、高防節點或者反向代理，DNS 解析返回的就是邊緣節點的防護 IP，而不是你的來源站 IP。所以在看測試結果前，先搞清楚網站當前到底有沒有掛載這類邊緣網路，避免盲目懷疑伺服器設定。

八、Ping、TCPing、DNS 和 HTTP 測試應該怎麼配合？

如果目標是判斷「網站到底能不能正常訪問」，只做 Ping 通常不夠。幾個常見測試解決的問題其實不同：

實際排查可以按照：

DNS
 ↓
Ping
 ↓
TCPing
 ↓
HTTP / HTTPS
 ↓
網站測速

逐層往下。

DNS 正常，但 Ping 不通

檢查網路線路以及 ICMP 是否被禁止。

Ping 正常，但 TCP 443 不通

檢查伺服器安全群組、防火牆和 Web 連接埠。

TCP 443 正常，但 HTTPS 返回 502

網路連線基本已經建立，問題應該繼續往 CDN 回源、反向代理或者上游應用服務查。

HTTP 200 正常，但頁面打開很慢

這時候連通性基本沒問題，需要繼續檢查：TTFB；資料庫；CDN快取；圖片；JavaScript；CSS；第三方資源這些，這樣排查會比只盯著一個 Ping 數字有效得多。

Ping 一個網站並不難，真正有用的是知道測試完成之後下一步應該看什麼。網域沒有解析出 IP，先檢查 DNS；能夠解析但是沒有 Ping 回應，就繼續判斷是網路問題還是 ICMP 被限制；Ping 正常而網站依然打不開，則應該盡快檢查 TCP 80/443、TLS、HTTP 和 Web 服務，而不是繼續在 Ping 上浪費時間。

如果只是排查自己電腦的網路，本機 Ping 已經非常方便。但站在網站維運的角度，還需要確認不同地區和不同電信業者是不是都正常。尤其是遇到「自己這裡正常、部分使用者打不開」的情況，Chahu多節點 Ping 往往能夠更快發現問題究竟集中在哪條線路。

相關問答

1. Ping 的時候延遲突然從 30ms 跳到 300ms，過幾秒又降回來，怎麼回事？

這種偶發抖動一般是中間路由器瞬時擁塞，或者 Wi-Fi 被干擾了。如果是無線網路，先換網路線試試。如果有線也這樣，可能是電信業者骨幹網某個節點在高峰期抖動，或者機房出口頻寬被其他業務擠了一下。偶爾一次不用管，頻繁出現才值得用 MTR 持續跑一段時間看看是哪一跳在跳。

2. 線上 Ping 工具顯示逾時，但我本機 Ping 完全正常，該信哪個？

兩個都信，因為它們測的不是同一條路。你本機正常只代表你這條線路沒問題，線上工具的逾時節點可能真的有問題，也可能是那個節點本身禁了 ICMP。這時候可以點開線上工具的具體節點，看看有沒有 TCP 測試選項，或者換個時間再測一次。如果多個節點都逾時，而你本機一直正常，那問題大概率在那些節點所在的電信業者或地區。

3. 伺服器完全禁 Ping，有沒有別的辦法確認它還活著？

有。最直接的是 TCPing，測 80 或 443 連接埠通不通。如果連接埠通，說明伺服器和 Web 服務都在跑。還可以用 curl 拉一下首頁標頭資訊，看有沒有返回 200。再不行就 telnet 連接埠，能連上就說明網路層和服務層至少有一個是活的。禁 Ping 只是關了 ICMP，不代表伺服器掛了，別自己嚇自己。

4. Ping 國外伺服器延遲 200ms 以上，除了換機房還有救嗎？

有，但效果有限。物理距離擺在那裡，光速繞不過去。能做的包括：走優化線路（例如 CN2 GIA）、上 CDN 把靜態資源推到離使用者近的節點、開 TCP 加速或 QUIC。但如果是動態請求要回源，延遲還是降不下來。所以做外貿站的話，盡量選目標使用者所在地區的機房，比什麼加速都管用。

5. 網站間歇性打不開，Ping 幾分鐘都正常，怎麼抓到問題？

這種情況最頭疼，因為故障窗口很短。可以開一個持續 Ping 視窗掛著，同時用瀏覽器或 curl 循環存取，記錄下打不開的時間點。然後對照 Ping 記錄，看那個時間點有沒有丟包或延遲飆升。如果沒有，問題就在應用層，可能是資料庫連線池滿了、後端逾時或 CDN 回源抖動。這時候 Ping 幫不上忙，得去看伺服器日誌和監控。