連接埠通不通怎麼檢測？TCPing 線上測試與故障排除方法

連接埠通不通不能只看 Ping。伺服器 IP 能正常回應，並不代表 80、443、22 等 TCP 連接埠一定可以連線。本文介紹 TCPing 線上測試的使用方法，並結合連線成功、連線逾時、連線被拒絕等常見結果，講解如何排查服務監聽、防火牆、安全群組、CDN/WAF、高防策略及網路路由問題，幫助站長和維運人員快速定位連接埠連線故障。

Chahu 團隊2026-09-085 分鐘閱讀

伺服器明明可以 Ping 通，網站卻一直打不開；網域解析看起來沒有問題，SSH、API 或某個業務服務卻始終提示連線逾時。遇到這種情況，問題往往已經不是「伺服器線上不在線」，而是對應的 TCP 連接埠到底能不能正常建立連線。

比如網站通常需要檢查 80、443 連接埠，SSH 常見的是 22 連接埠，一些 API、面板或自建服務還會使用其他連接埠。單純 Ping 一個 IP，只能幫助判斷基本網路連通情況，並不能證明這些連接埠一定可以存取。

這時候，TCPing 就比普通 Ping 更直接。透過 TCPing，可以針對某個網域或 IP 的指定 TCP 連接埠發起連線測試，快速判斷是連接埠本身無法存取，還是問題已經進入 HTTP、應用程式或者其他更上層的環節。下面就從實際排障出發，看看連接埠通不通應該怎麼檢測，以及 TCPing 出現逾時、拒絕連線以後應該從哪裡查起。

一、連接埠通不通，到底是在檢測什麼？

我們平時存取一個網站或者連線一台伺服器，不只是要找到正確的 IP，還需要連線伺服器上對應的服務連接埠。

例如：

服務	常見連接埠
HTTP	80
HTTPS	443
SSH	22
FTP	21
MySQL	3306
PostgreSQL	5432
Redis	6379
Windows 遠端桌面 RDP	3389

以 HTTPS 網站為例。

瀏覽器存取：

https://www.example.com/

網域完成 DNS 解析以後，用戶端通常還需要連線目標伺服器或者 CDN 節點的 TCP 443 連接埠，然後才能繼續進行 TLS 握手和後面的 HTTPS 請求。

整個過程可以簡單理解成：

輸入網域
   ↓
DNS解析得到IP
   ↓
連線TCP 443連接埠
   ↓
TLS握手
   ↓
傳送HTTPS請求
   ↓
伺服器回傳頁面

所以，我們平時說「443 連接埠通不通」，實際想確認的是：目前測試節點能不能和目標位址的 TCP 443 連接埠正常建立連線。這也是排查網站打不開時經常被忽略的一點：伺服器 IP 能存取，不等於業務連接埠一定能存取。一台伺服器完全可能處於線上狀態，但由於 Nginx 沒有啟動、安全群組沒有放行或者防火牆攔截，導致 443 連接埠無法從公網建立連線。

二、Ping 能通，為什麼連接埠還是可能不通？

很多人在排查伺服器時，第一步都會先 Ping。

例如：

ping example.com

如果能收到正常回應，往往會下意識認為：「伺服器是通的，網路應該沒問題。」實際上，這個判斷只能算對了一半。Ping 主要使用 ICMP 協定，它更適合觀察目標主機有沒有回應、網路往返延遲大概是多少，以及是否存在明顯丟包。TCPing 測的卻不是 ICMP，而是指定的 TCP 服務連接埠。

例如：

目標伺服器
IP：203.0.113.10

Ping：
正常

TCP 443：
Timeout

這種結果並不矛盾。它說明伺服器在網路層面仍然能夠回應 ICMP，但存取 HTTPS 所需的 TCP 443 連接埠並沒有正常建立連線。反過來也一樣。有些伺服器、CDN 或防火牆會主動停用 ICMP Ping，此時可能出現：

Ping：
100%逾時

TCP 443：
正常

網站照樣能夠正常開啟。因此，實際排障時最好把幾種工具分開理解：

檢測方式	主要解決的問題
Ping	IP 是否回應、延遲和丟包情況
TCPing	指定 TCP 連接埠能不能連線
HTTP 檢測	網站回傳 200、301、404 還是 500 等狀態碼
Traceroute / MTR	資料經過哪些路由、故障可能出現在哪一段
DNS 查詢	網域是否解析到了正確位址

如果只是想確認 80、443、22 或其他 TCP 連接埠到底開沒開、能不能從公網連線，TCPing 通常比普通 Ping 更直接。

三、如何使用 TCPing 線上測試

偶爾檢查一個伺服器連接埠，沒有必要專門登入伺服器或者安裝 TCPing 用戶端。直接使用線上 TCPing 工具，從公網節點向目標位址發起測試，通常會更方便。尤其是遇到「我這裡可以存取，其他地區使用者卻打不開」這種問題時，只在自己電腦上測試一次參考價值並不高。

使用 Chahu 進行 TCPing 線上檢測

Chahu 的網路檢測工具可以把 Ping、TCPing、HTTP(S) 和 Traceroute 等測試結合起來使用，比較適合網站和伺服器的連續故障排查。其 TCPing 可以用來驗證指定連接埠的 TCP 連通情況，而不是只檢查 ICMP 是否回應。

具體步驟：

實際測試並不複雜：首先輸入需要檢查的網域或者伺服器 IP，例如：

www.example.com

或者：

203.0.113.10

接著填寫需要檢測的 TCP 連接埠。如果是普通網站，可以先檢查：80

HTTPS 網站則主要檢查：443

SSH 服務通常檢查：22

設定完成以後開始測試，節點會嘗試連線目標位址對應的 TCP 連接埠。

這裡真正值得關注的，不只是「通」或者「不通」，還應該看：

哪些測試節點連線成功；
哪些地區出現逾時；
電信、聯通、行動之間有沒有明顯差異；
TCP 連線耗時是否異常；
實際連線到了哪個回應 IP。

Chahu 本身採用多地區探測節點進行網路測試，這類多節點結果最大的價值不是單純告訴你「連接埠失敗了」，而是幫助判斷故障範圍。

例如：

北京電信     正常
上海聯通     正常
廣州行動     正常
成都電信     逾時
重慶電信     逾時

這種結果和：

北京電信     逾時
上海聯通     逾時
廣州行動     逾時
成都電信     逾時
重慶電信     逾時

排查方向明顯不一樣：前者更像區域線路、電信商或者存取策略問題，後者才更應該優先檢查伺服器、防火牆、安全群組和服務狀態。還有一點需要注意：如果網域已經接入 CDN，TCPing 網域檢測到的通常是 CDN 邊緣節點連接埠，而不是源站連接埠。如果你真正想確認源伺服器的 443 或其他連接埠是否正常，還需要使用源站 IP 單獨測試。

四、TCPing 測試結果怎麼看？

TCPing 做完以後，不要只看到一個紅色或者綠色狀態就結束。不同的失敗結果，背後的含義並不完全一樣。

1. TCP 連線成功

例如測試結果顯示：

TCP 443
Connected
38 ms

說明目前測試節點已經可以和目標位址的 TCP 443 連接埠正常建立連線。

至少可以確認：

目標 IP 目前可以到達；
443 連接埠不是完全無法存取；
目前測試節點沒有被入口防火牆完全攔截。

但要注意：TCPing 成功，不代表網站一定正常。因為 TCP 連線只是網站存取過程中的其中一步。後面還有：

TCP連線
   ↓
TLS握手
   ↓
HTTP請求
   ↓
Web伺服器
   ↓
應用程式
   ↓
資料庫

所以完全可能出現：

TCP 443：正常
HTTP：502 Bad Gateway

或者：

TCP 443：正常
HTTP：500 Internal Server Error

這時候繼續反覆測連接埠已經意義不大，應該轉向 HTTP 狀態碼、Web 服務和應用日誌。

比如 Chahu 的 HTTP 狀態檢測工具就可以繼續檢查頁面到底回傳 200、301、302、404、500 還是其他狀態。

2. Connection Timed Out：連線逾時

TCPing 中比較常見的失敗就是 Timeout。

簡單來說，就是測試節點嘗試建立 TCP 連線，但在等待時間內始終沒有獲得正常回應。

常見原因包括：

雲伺服器安全群組沒有放行該連接埠；
Linux 或 Windows 防火牆直接丟棄連線；
IDC 或上游防火牆攔截；
CDN 或高防安全策略限制；
線路或路由異常；
目標伺服器已經失聯；
某些地區或 IP 段受到存取限制。

這裡有一個很容易誤判的地方：TCPing 逾時並不能簡單等同於「伺服器沒有開放這個連接埠」。因為如果中間某一層防火牆直接把資料封包丟掉，你看到的同樣可能是 Timeout。所以出現逾時以後，應該繼續結合節點範圍、伺服器監聽情況和防火牆規則判斷。

3. Connection Refused：連線被拒絕

如果看到：

Connection Refused

情況和 Timeout 又不一樣。

連線被拒絕通常意味著請求已經能夠到達目標主機，但目標連接埠沒有正常接受這個連線。

例如：

伺服器線上
   ↓
網路正常
   ↓
請求到達伺服器
   ↓
443連接埠沒有服務監聽
   ↓
Connection Refused

這時候應該優先檢查：

Nginx、Apache 是否啟動；
SSH 服務是否正常；
應用程式有沒有執行；
程式是否監聽了正確連接埠；
服務是不是只監聽了 127.0.0.1；
服務是否剛剛崩潰或者重啟失敗。

相比一直檢查網路線路，這時候直接登入伺服器看服務狀態通常會更快。

五、連接埠不通應該怎麼排查？

遇到連接埠不通，最怕沒有順序地到處檢查。一會兒改 DNS，一會兒重啟 Nginx，一會兒又去看防火牆，折騰半天最後才發現只是雲平台安全群組忘記放行。實際處理時，可以沿著下面這條鏈路往下查：

網域解析是否正常
        ↓
目標IP是否正確
        ↓
TCP連接埠是否可連線
        ↓
伺服器是否監聽該連接埠
        ↓
系統防火牆是否放行
        ↓
雲伺服器安全群組是否放行
        ↓
CDN / WAF / 高防是否攔截
        ↓
網路路由是否異常

1. 先確認 DNS 有沒有解析錯

如果你測試的是：

example.com:443

第一步最好先確認網域究竟解析到了哪個 IP。

尤其是剛剛：

更換伺服器；
修改 DNS 記錄；
接入 CDN；
切換高防 IP；
調整智慧解析；

之後出現存取異常，更應該先看 DNS。

因為如果網域已經解析到了錯誤的伺服器，後面測多少次 443 都沒有意義。

如果發現不同地區解析結果不同，也不要馬上認為 DNS 出問題。使用 CDN 或智慧 DNS 時，本身就可能根據地區和電信商回傳不同 IP。

真正需要確認的是：

這些 IP 是不是你目前業務應該使用的節點位址。

2. 再看伺服器基本連通情況

DNS 沒問題以後，可以配合 Ping 看一下目標 IP 的基本網路狀態。

如果多個地區都可以正常 Ping，而且延遲也比較穩定，至少說明目標伺服器的基礎網路連線大概還在。

但如果 Ping 逾時，也不要立即判定伺服器當機。

因為伺服器完全可能停用了 ICMP。

Chahu 官方的網路排障內容也提到，Ping 只能作為參考；如果伺服器或 CDN 禁止 ICMP，Ping 100% 丟包時 HTTP 服務依然可能正常，因此還需要繼續驗證 TCP 80、443 等實際業務連接埠。

3. 檢查伺服器有沒有監聽對應連接埠

這是連接埠故障裡非常常見的一種情況。

比如 HTTPS 網站應該監聽：

但 Nginx 服務沒有啟動，公網存取自然失敗。

Linux 伺服器可以執行：

ss -lntp

部分系統也可以使用：

netstat -lntp

如果 443 正常監聽，通常會看到類似：

LISTEN 0 511 0.0.0.0:443

如果完全找不到 443，就應該檢查 Web 服務設定，而不是繼續查外部線路。

還需要特別注意監聽位址。

例如：

127.0.0.1:8080

表示服務只監聽本機回環位址。

你在伺服器內部存取可能完全正常，但公網裝置無法直接連線。

4. 檢查伺服器防火牆

服務已經監聽，公網 TCPing 還是逾時，就要繼續檢查系統防火牆。

常見的包括：

firewalld；
iptables；
nftables；
Windows Defender Firewall。

例如伺服器上 Nginx 明明監聽：

0.0.0.0:443

但防火牆沒有允許外部 TCP 443 流量，公網測試仍然會失敗。

這種情況下最容易出現：

伺服器本機 curl：正常
公網 TCPing：逾時

5. 檢查雲伺服器安全群組

如果使用阿里雲、騰訊雲、AWS、Azure 或其他雲伺服器，還要注意系統防火牆外面通常還有一層安全群組。

這是很多新伺服器「本機服務都正常，公網就是連不上」的真正原因。

例如你新部署了一個服務：

TCP 8443

程式已經啟動：

0.0.0.0:8443

本機存取也正常。

但公網 TCPing 一直 Timeout。

這時候就應該看看雲平台安全群組的入站規則裡，有沒有允許 TCP 8443。

6. 檢查 CDN、WAF 和高防策略

如果網站接入了 CDN、WAF 或高防服務，實際存取鏈路會再多一層。

例如：

使用者
 ↓
CDN / 高防
 ↓
源站

此時使用者能夠連線 CDN 的 443，並不能說明 CDN 一定能夠連線源站。

可能出現：

用戶端 → CDN 443：正常
CDN → 源站 443：失敗

最終表現出來可能不是瀏覽器「連線逾時」，而是：

502 Bad Gateway
504 Gateway Timeout

這時候應該繼續檢查：

CDN 回源連接埠；
源站防火牆；
源站 IP 白名單；
回源協定 HTTP/HTTPS；
Origin Host 設定；
高防存取控制；
WAF 安全規則。

六、幾個常見的連接埠故障場景

實際處理網路問題時，大部分故障都不會告訴你「安全群組 443 連接埠未開放」這麼清楚。看到的通常只是「網站打不開」「SSH 連不上」或者「介面突然逾時」。下面幾種情況比較典型。

場景一：Ping 正常，但 443 連接埠不通

例如：

DNS：正常
Ping：正常
TCP 443：Timeout

優先檢查：

Nginx / Apache
      ↓
443是否監聽
      ↓
系統防火牆
      ↓
雲安全群組
      ↓
CDN / 高防策略

這時候繼續研究 Ping 延遲意義已經不大。

場景二：80 連接埠正常，443 連接埠不通

例如：

TCP 80：正常
TCP 443：失敗

說明伺服器整體網路並沒有斷。

問題明顯集中在 HTTPS 入口。

優先檢查：

443 監聽狀態；
HTTPS 虛擬主機設定；
防火牆 443 規則；
雲伺服器安全群組；
CDN HTTPS 設定。

SSL 憑證本身設定錯誤通常發生在 TCP 建連之後，因此如果連 443 TCP 都完全建立不了，不應該一開始就把重點放在憑證上。

場景三：伺服器本機能連線，外網連線失敗

例如伺服器內部執行：

curl http://127.0.0.1:8080

可以正常回傳，但外部測試：

203.0.113.10:8080

一直逾時。

這時候優先檢查：

服務監聽位址
安全群組
系統防火牆
NAT
連接埠對映
IDC ACL

尤其要確認程式是不是只監聽了：

127.0.0.1:8080

而不是：

0.0.0.0:8080

場景四：只有某個電信商連線失敗

例如：

電信：正常
聯通：正常
行動：大面積逾時

這時候優先查：

行動到機房的路由；
CDN 行動節點；
BGP 路由；
防火牆 IP 段規則；
地區存取控制；
高防清洗線路。

可以再結合 Traceroute 或 MTR 判斷故障從哪一段開始。

場景五：TCPing 正常，但網站還是打不開

這是另一個很常見的誤區。

例如：

TCP 443：正常
網站：打不開

TCP 已經能夠正常建立連線，就沒必要一直圍著「連接埠有沒有開放」打轉。

接下來應該檢查：

TLS握手
   ↓
HTTP狀態碼
   ↓
Web伺服器
   ↓
PHP / Java / Node.js 等應用
   ↓
資料庫
   ↓
第三方API

如果已經回傳了 403、404、500、502 或 504，說明問題已經進入 HTTP 或應用層

七、TCPing、Ping 和 HTTP 檢測應該怎麼選？

遇到網路故障以後，沒必要把所有檢測工具同時跑一遍，先看自己到底想確認什麼：

目前問題	建議優先檢測
想知道伺服器 IP 有沒有回應	Ping
想檢測 80、443、22 等 TCP 連接埠	TCPing
想知道網頁回傳什麼狀態碼	HTTP 狀態碼檢測
想判斷網域有沒有解析錯誤	DNS 查詢
想查網路從哪裡開始異常	Traceroute / MTR
想檢查 HTTPS 憑證問題	SSL/TLS 檢測

例如網站打不開，可以按照下面的順序排：

DNS
 ↓
Ping
 ↓
TCPing 80 / 443
 ↓
HTTP / HTTPS
 ↓
Traceroute / MTR

當然，這不是絕對固定的流程。如果瀏覽器已經明確回傳：

HTTP 500

那就說明 DNS、TCP 和 HTTP 通訊至少已經進行到了伺服器回應這一層，沒必要再從頭研究 Ping。

如果已經看到：

403 Forbidden

也說明請求大概已經到達 CDN、WAF 或 Web 服務，這時候重點應該轉向存取控制和安全規則。真正有效的故障排查，不是把所有工具全部測試一遍，而是根據目前結果決定下一步查哪一層。

檢測伺服器連接埠是否正常，最容易出現的誤區就是只看 Ping。伺服器能 Ping 通，只能說明目前網路具備一定的 IP 連通性，並不能證明網站需要的 80、443，或者 SSH、API 使用的其他 TCP 連接埠一定能夠建立連線。反過來，Ping 逾時也不代表伺服器一定當機，因為很多伺服器和 CDN 本身就會限制 ICMP。實際排查時，可以先用 TCPing 對業務連接埠進行測試，再結合不同地區、不同電信商的結果判斷故障範圍。

如果所有測試節點都無法連線，優先檢查服務監聽、系統防火牆和雲伺服器安全群組；如果只有某個地區或者電信商異常，就應該進一步查看路由、CDN 節點和存取控制策略；如果 TCPing 已經正常，但網頁仍然打不開，則應該繼續檢查 TLS、HTTP 狀態碼以及伺服器應用。按照這個順序一層層排查，比看到網站打不開就反覆重啟伺服器要有效得多。