部落格 / 網路基礎

ping 不通但網站能開啟？tcping 與 ICMP ping 的區別和正確用法

2026-10-25cdnping 編輯部約 7 分鐘讀完

ping 不通但網站能開啟，最常見的原因是對方或中間網路過濾了 ICMP，而網頁走的是 TCP 443，兩者互不相干。想知道某個服務“到底通不通、有多遠”，應該用 tcping 這類工具直接對業務埠發起 TCP 握手，或者用 curl -w 把 DNS、TCP、TLS 各段時間拆開看。tcping 比 ping 更接近真實訪問，但也有兩個容易讀錯的地方：RST 和本機代理。

#ping 不通為什麼網站還能開啟？

ping 發的是 ICMP Echo Request，等對方回一個 Echo Reply。它不經過任何埠，也不經過 Web 伺服器，回應它的是對方作業系統的網路棧，或者更早的某個裝置。

ICMP 在下面幾種情況下會“失真”：

• 被直接過濾：不少雲伺服器的安全組預設不放行入站 ICMP，部分 API 入口和 CDN 節點也不回應 ping。這時 ping 100% 超時，但 443 埠完全正常。
• 被限速或降低優先順序：路由器對發給自己的 ICMP、以及 TTL 超時報文的生成，通常交給控制面處理並限速；有的網路還會對經過的 ICMP 整體限速。於是 ping 顯示的延遲偏高、偶爾丟包，而同一路徑上的 TCP 流量並沒有受影響。這也是 traceroute 中間跳出現星號或延遲突增的常見原因，讀法見 traceroute 和 mtr 結果怎麼看。
• 走了不同的路徑：有的網路對 ICMP 和 TCP 做不同的策略路由，代理軟體一般也只接管 TCP（和部分 UDP），ICMP 仍然從本地出口直接發出。開著代理 ping 一個海外域名，測到的是“本地直連”的路徑，而瀏覽器訪問走的是代理，兩者沒有可比性。

所以 ping 的結論只能是“ICMP 這條路的情況”。它通了，不代表 443 能用；它不通，也不代表服務掛了。

#tcping 測的到底是什麼？

tcping 對指定的 IP 和埠發起一次 TCP 連線：發出 SYN，等對方回 SYN-ACK，記下這個往返用了多久，然後關閉連線。它測的是 TCP 三次握手的第一個往返，不發 HTTP 請求，也不做 TLS 握手。

和 ping 相比，它有兩點更貼近真實訪問：

1. 用的是業務協議和業務埠，能被 ICMP 過濾規則影響的情況少了一大類。
2. 能順便回答“埠開沒開”：收到 SYN-ACK 說明有程式在監聽。

#RST 也算“有響應”：最容易看錯的地方

TCP 握手有三種結果：

問題出在第二行。RST 也是一個完整的往返，有些工具（尤其是發原始 SYN 包的工具，比如 hping3）會把它的耗時照常列印出來，只在標誌位裡寫著 RA。只看數字的話，會誤以為“埠通，延遲 40 ms”。讀 tcping 結果時，先確認狀態是 open，再看耗時。

#本機代理會“替”對方完成握手

開啟 TUN 模式或透明代理時，很多代理客戶端會在本機直接接受 TCP 連線，再轉發出去。此時 tcping 任何海外地址都可能顯示 1 ms 左右、埠全開，測到的只是你和本機代理之間的握手。CDN 也有類似情況：TCP 在離你最近的邊緣節點就終止了，tcping 測到的是你到邊緣的距離，不是到源站。

判斷方法很簡單：同一個目標，關掉代理測一次、開著代理測一次；或者 tcping 一個肯定不存在服務的地址和埠，如果也“秒通”，說明握手被本地接管了。

#三種測量方式放在一起對比

越往右越接近應用實際遇到的情況，代價是測量更重、受更多因素影響。排查時建議從右往左用：先用 curl 看哪一段慢，再用 tcping 確認 TCP 層，最後才看 ping 和 traceroute。

#各系統怎麼測埠和握手延遲？

下面以 api.openai.com:443 為例。示例輸出只用來說明格式，數字不是實測值。

#Windows：tcping.exe 與 PowerShell

Windows 沒有自帶 tcping，常見的是一個單檔案的 tcping.exe，下載後放進任意在 PATH 裡的目錄即可。請從專案的原始釋出頁下載，下載後核對數字簽名或雜湊。

tcping -n 5 api.openai.com 443

輸出大致是每行一次探測，帶 Port is open 和 time=xx.xxxms，最後給出最小、最大、平均值。如果顯示 No response，就是超時。

不想裝軟體的話，PowerShell 自帶的命令可以判斷埠是否開放：

Test-NetConnection api.openai.com -Port 443

看 TcpTestSucceeded : True 即可。它不適合用來測延遲，結果裡的 PingReplyDetails 是 ICMP 的資料，不是 TCP 握手時間。

#macOS 與 Linux：nc 和 nping

nc（netcat）系統一般自帶：

nc -vz -w 3 api.openai.com 443

succeeded / open 表示握手成功，Connection refused 對應 RST，超時說明沒有回應。nc 不列印耗時，需要的話套一層 time：

time nc -z -w 3 api.openai.com 443

這樣測到的時間包含 DNS 解析，想排除 DNS 就直接寫 IP。

需要連續測、看抖動時，可以用 nmap 附帶的 nping，它的 --tcp-connect 模式走系統的正常 connect，不需要 root：

nping --tcp-connect -p 443 -c 10 api.openai.com

最後一行會給出 Max rtt / Min rtt / Avg rtt。Linux 發行版倉庫裡也有叫 tcping 的包，不同發行版的實現不一樣，引數以 tcping -h 為準。

#通用：curl -w 拆分每一段時間

這是測 API 最推薦的一條命令，三個系統都能用（Windows 10 1803 及之後的版本自帶 curl，PowerShell 裡要寫 curl.exe，並把 -o /dev/null 換成 -o NUL）：

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\n首位元組: %{time_starttransfer}s\n總計: %{time_total}s\n" https://api.openai.com/v1/models

這幾個值都是從開始計時的累計時間，要相減才是每一段：

• time_connect - time_namelookup：TCP 握手，和 tcping 測的是同一個東西。
• time_appconnect - time_connect：TLS 握手。
• time_starttransfer - time_appconnect：請求發出到收到第一個位元組，包含服務端處理。不帶金鑰訪問 /v1/models 通常直接返回 401，這一段基本就是“網路往返 + 閘道器處理”，不涉及模型推理。

如果 curl 走了代理（設定了 https_proxy 等環境變數），time_connect 測到的是連代理的時間。想區分，就用 --noproxy '*' 再跑一次對比。連線階段之後的延遲怎麼繼續拆，見 AI API 延遲拆解：連線建立、閘道器往返與首 token 時間。

#為什麼測 AI API 應該測 443，而不是 ping 域名？

多數 AI API 的入口在 CDN 或雲負載均衡後面，對 ping 的處理各不相同：有的回應，有的不回應，有的由邊緣節點代答。ping 一個 API 域名得到的結果，既不能說明 443 可用，也不能拿來橫向比較各家快慢。

實際呼叫要經過的是：DNS 解析 → TCP 443 握手 → TLS 握手 → HTTP 請求。任何一段出問題，ping 都看不出來。比較典型的幾種：

• DNS 解析到了錯誤的地址：ping 可能通（只是 ping 錯了物件），請求卻失敗。是否被汙染或劫持，可以按 DNS 汙染和 DNS 劫持的三步判斷來查。
• TCP 443 被重置或丟棄：ping 正常，tcping 顯示 closed 或超時。
• TLS 握手失敗或特別慢：ping 和 tcping 都正常，只有 curl 的 TLS 段異常或報錯。

所以排查 Claude Code、Codex 這類工具連不上時，應該按層次逐一檢查，而不是 ping 一下就下結論。完整的分層清單見 Claude Code 連線超時和報錯怎麼排查。

#一份可以照做的檢查順序

1. 執行上面的 curl -w 命令，看在哪一段出錯或變慢。
2. DNS 段慢或報解析錯誤：換一個解析器對比 dig / nslookup 結果。
3. TCP 段超時：用 tcping 或 nc -vz 測 443，開關代理各測一次，確認是不是被本機代理接管。
4. TLS 段報錯：檢查系統時間、代理證書、是否有中間裝置在做 HTTPS 解密。
5. 連線都正常但請求失敗：看 HTTP 狀態碼，再去 API 狀態頁 確認上游有沒有事件。
6. 最後才用 ping 和 mtr 看路徑，判斷是不是中間某段網路有問題。

日常需要定期做的專案，可以對照 開發者網路自檢清單（2026 版）。

#cdnping 首頁的“首次連線”和“往返”分別對應什麼？

cdnping 的線上測速在瀏覽器裡測 15 個 AI 模型 API 和 9 個公共前端 CDN，給出兩個數字，和前面三種測量可以這樣對上：

兩個數字差得多，說明大部分時間花在建連上：DNS 慢、RTT 大導致 TCP 和 TLS 握手被放大，或者 TLS 握手本身有問題。這種情況下，客戶端開啟連線複用（keep-alive、HTTP/2）收益最大。兩個數字都高，說明你和入口之間的往返本身就遠，複用連線也省不掉。

瀏覽器測速走的是瀏覽器的網路棧，開著代理就會經過代理，所以它反映的是“你的瀏覽器實際訪問這些 API 的情況”，這一點和 tcping 在 TUN 模式下只測到本機不同。測量細節見 資料方法。如果想確認自己的出口 IP、是否走了代理、瀏覽器往返和出口 TCP 往返是否對得上，可以用 IP 與環境檢測，其中延遲特徵一項正是拿瀏覽器往返和 Cloudflare 測得的出口 TCP 往返做對比，原理見 網站如何用延遲判斷你在用代理。

#一份邊緣探測資料怎麼讀

cdnping 的 API 狀態頁 從 Cloudflare 邊緣每 5 分鐘探測一次各官方 API 入口。下面取自 2026-10-17 的首批快照：探測節點是 DEN（美國丹佛），視窗為 UTC 08:40–10:05，所有入口合計 242 次探測。cdnping 從這一天才開始採集，資料只覆蓋這一個多小時，不是長期統計。資料以 CC BY 4.0 釋出。

這些數字主要反映丹佛到各入口的網路距離，海外入口和國內入口的差距來自地理位置，不說明哪家服務更快。中位數和 P95 的差距可以多看一眼：同樣的探測，有的入口 P95 接近中位數，有的接近兩倍，後者意味著偶發的慢請求更多。你在自己的網路裡用 tcping 或 curl 測，排序和數值都可能完全不同，結論要以本地實測為準。