IPv6 連接埠怎麼測試？線上檢測 80、443、22 連接埠是否開放

伺服器已經配置了 IPv6，網域的 AAAA 記錄也解析正常，Ping IPv6 位址時還能收到回應，但網站就是打不開，SSH 也連不上。遇到這種情況，繼續反覆 Ping 往往查不出真正的問題。因為IPv6 位址可以存取，不代表伺服器上的業務埠一定可以連線。

Ping 主要用來判斷 IPv6 網路是否基本可達，而網站、SSH、API 等服務最終依賴的是具體 TCP 埠。例如 HTTPS 網站通常需要連線 443 埠，HTTP 使用 80 埠，SSH 常見的是 22 埠。如果伺服器只允許 ICMP，卻沒有放行對應 TCP 埠，就可能出現「IPv6 Ping 正常，但網站存取失敗」的情況。

所以，在確認 IPv6 基礎連通性之後，下一步通常就是做 IPv6 埠測試。本文將從 IPv6 埠測試方法入手，具體介紹 80、443、22 等常見埠怎麼檢測、測試結果怎麼看，以及遇到 IPv6 能 Ping 通但埠不通時應該如何排查。

一、為什麼 IPv6 能 Ping 通，埠卻不一定能存取？

在 IPv6 網站部署和伺服器維運中，不少人蔀會遇到一個奇特現象：在終端裡執行 IPv6 Ping 指令，明明能收到正常的延遲回應，但用瀏覽器開啟網站卻一直提示逾時，甚至用終端連線 SSH 也直接報錯。

這種「IPv6 能夠 Ping 通，但服務埠打不開」的情況其實非常常見。

出現這個問題，本質上是因為 Ping 和網站存取驗證的完全是兩個不同層級的網路環節。

當我們試圖透過 IPv6 存取一個網站或者遠端伺服器時，整個資料傳輸流程實際上需要按順序通過以下幾個關卡：

1. IPv6 位址鏈路可達（基礎網路連通）

2. TCP 埠建立連線（傳輸層通道開啟）

3. TLS / SSH 協定握手（加密與身分驗證）

4. 應用服務回應（Web / SSH 服務正常運作）

Ping 指令的作用，僅僅是驗證了第一關。

Ping 使用的是 ICMPv6 協定，它的主要職責是測試本機裝置到目標 IPv6 位址之間的網路通路是否順暢。只要網路卡配置了 IPv6 位址、閘道無誤且沿途路由器沒有攔截 ICMP 封包，Ping 就能回應漂亮的延遲數據。

但這並不意味著後面的關卡也是暢通的。

比如常見的 HTTPS 網站，它依賴傳輸層的 TCP 443 埠；HTTP 依賴 80 埠；而 SSH 遠端管理則依賴 22 埠。如果在伺服器端，系統防火牆攔截了 TCP 443 的入站流量，或者 Web 服務本身根本沒有在 IPv6 位址上開啟監聽，就會導致非常典型的故障現象：

• IPv6 Ping 測試：正常回應（延遲 28ms）

• TCP 443 埠測試：連線逾時

• HTTPS 網站存取：無法開啟

反過來的情況也同樣成立。出於安全考量，很多企業級伺服器和資料中心機房會直接停用 ICMP Echo 回應。此時去 Ping 伺服器的 IPv6 位址會全部顯示逾時，但只要伺服器放行了 TCP 埠，HTTPS 網站和 SSH 服務依然能夠正常存取。

因此，在排查 IPv6 網站打不開或服務連線失敗等故障時，不能把 Ping 的結果當作服務是否可用的唯一標準。確認 IPv6 位址能夠到達之後，更關鍵的一步是針對具體的 TCP 業務埠進行深入檢測。

二、IPv6 埠測試到底在測試什麼？

所謂 IPv6 埠測試，本質上是在判斷：測試裝置能否透過 IPv6 網路，與目標伺服器指定的 TCP 埠建立連線。

這裡涉及兩個關鍵條件：一個是 IPv6 網路本身能夠到達目標伺服器；另一個是伺服器對應埠確實處於可連線狀態。

不同業務需要檢查的埠也不同。

Ping 和 IPv6 埠測試有什麼區別？

很多人排查 IPv6 問題時最容易混淆的就是 Ping 和 TCP 埠檢測，兩者雖然都可以判斷「網路通不通」，但測試的層級不同。

例如網站存取異常時，如果 IPv6 Ping 正常，下一步就不應該繼續盯著 Ping 延遲，而應該直接測試 80 或 443 埠。這也是為什麼伺服器能夠 Ping 通，卻依然可能打不開網站。

三、IPv6 埠怎麼測試？

IPv6 埠測試並不複雜。臨時排查可以使用 Windows、Linux 內建的指令，如果需要判斷不同地區、不同電信業者存取同一個 IPv6 埠是否存在差異，則更適合搭配線上 TCPing。

1. 使用 Chahu 線上 TCPing 測試 IPv6 埠

如果想從公網環境檢查伺服器埠，可以使用 Chahu 的 TCPing：

https://www.chahu.com/tcping

Chahu 的 TCPing 主要用於檢測指定 TCP 埠的連通狀態和連線耗時，並可以從不同地區及電信業者節點進行測試。相比只在自己電腦上連線一次，這種方式更容易判斷埠異常究竟是伺服器本身的問題，還是只出現在某些網路環境。

實際測試邏輯並不複雜：

輸入網域或 IPv6 位址
        ↓
填寫需要檢測的 TCP 埠
        ↓
開始 TCPing
        ↓
查看不同節點連線結果
        ↓
判斷是全部失敗還是部分地區異常

比如測試 HTTPS 網站，就重點檢查 443 埠；SSH 無法連線，則檢查 22 埠。

真正值得看的不仅是「能不能連線」，還包括不同地區的結果是否一致。

假設檢測結果類似：

北京電信       443 正常
上海聯通       443 正常
杭州移動       443 正常
廣州移動       443 逾時
深圳移動       443 逾時

這種情況就不能簡單理解為「443 埠沒有開放」。因為如果埠真的完全關閉，通常不會只有個別線路出現問題。此時還需要繼續考慮 IPv6 路由、電信業者網路或者中間安全策略。

2. Windows 測試 IPv6 埠

Windows 可以直接透過 PowerShell 的Test-NetConnection測試 TCP 埠。

例如檢查 IPv6 伺服器的 443 埠：

Test-NetConnection -ComputerName 2001:db8:1234::10 -Port 443

執行後重點看：

TcpTestSucceeded : True

如果結果為：True說明目前電腦透過 IPv6 到目標伺服器的 TCP 443 基本可以建立連線；如果是：False 就需要繼續檢查埠監聽、防火牆、安全群組以及 IPv6 網路路徑。

對於網域也可以直接測試：

Test-NetConnection example.com -Port 443

不過在雙棧網站中，網域可能同時存在 A 和 AAAA 記錄。如果目的是專門排查 IPv6，最好同時確認實際連線使用的位址，避免把 IPv4 測試結果誤認為 IPv6 結果。

3. Linux 測試 IPv6 埠

Linux 下可以使用nc。

例如測試 IPv6 443 埠：

nc -6 -vz 2001:db8:1234::10 443

測試 SSH：

nc -6 -vz 2001:db8:1234::10 22

其中：

-6    強制使用 IPv6
-v    顯示詳細結果
-z    只檢查埠，不傳送業務資料

如果檢測 HTTPS 網站，還可以進一步使用：

curl -6 -I https://example.com

這一條就不只是判斷 TCP 443 能不能連線了，而是繼續檢查 IPv6 環境下 HTTPS 服務能否正常建立連線並回傳 HTTP 回應。

因此實際排查時可以逐層進行：IPv6 Ping→ TCP 443→ TLS→ HTTP Response

問題出現在哪一層，排查範圍也會小很多。

四、IPv6 80、443、22 連接埠分別怎麼判斷？

在實際排查過程中，不同業務連接埠對應的存取鏈路和排查重點其實各有側重。下面針對 80、443 和 22 這三個最核心的連接埠，分別梳理具體的操作思路和判斷邏輯。

IPv6 80 連接埠（HTTP 服務）

80 連接埠是傳統 HTTP Web 服務的基礎連接埠。使用者透過 80 連接埠發起存取的底層資料流向大致為：

使用者用戶端 → IPv6 傳輸鏈路 → TCP 80 連接埠握手 → Web 伺服器行程（如 Nginx/Apache）→ 回傳 HTTP 回應

如果在測試時發現 IPv6 Ping 完全正常，但 TCP 80 連接埠始終回應逾時，最常見的排查方向有兩個：

1. 服務監聽遺漏：Web 服務可能只綁定了 IPv4 位址（0.0.0.0:80），未開啟 IPv6 監聽；

2. 策略攔截：雲端伺服器平台的 IPv6 入站安全群組規則或系統內部防火牆（如ip6tables、nftables）未放行 TCP 80 連接埠。

需要注意的是，現在絕大部分網站都開啟了全站 HTTPS，通常會將 80 連接埠的流量透過 301 或 302 強制重導向至 443 連接埠。因此，80 連接埠測試成功僅代表 HTTP 基礎通路沒問題，並不能直接推斷出 443 連接埠也同樣可用，兩者必須獨立進行驗證。

IPv6 443 連接埠（HTTPS 服務）

443 連接埠是當前 IPv6 網站故障排查中最高頻、也最容易遇到複雜問題的環節。相比普通 HTTP，一次完整的 HTTPS 存取需要經過更嚴謹的協定互動：

IPv6 基礎網路 → TCP 443 連接埠連線 → TLS/SSL 加密握手 → 發送 HTTPS 請求 → Web 伺服器處理並回應

在排查 443 連接埠時，必須清晰區分兩種截然不同的故障現象：

• TCP 443 連接埠連線失敗（逾時或拒絕）：這屬於典型的傳輸層及網路層故障。排查優先級應放在雲端伺服器安全群組、系統防火牆、CDN 邊緣節點配置以及 IPv6 路由線路上。

• TCP 443 連接埠正常，但瀏覽器提示 HTTPS 錯誤：如果透過 TCPing 確認 443 連接埠可以順利建立連線，但網頁依舊打不開或報錯（如憑證無效、握手逾時、502 錯誤），則說明網路和連接埠本身已經通暢。此時不應再糾結於網路層，而應深入檢查 SSL/TLS 憑證是否匹配、SNI 配置是否正確、反向代理配置以及上游應用服務的運行狀態。

IPv6 22 連接埠（SSH 遠端管理）

22 連接埠通常用於 Linux 伺服器的 SSH 遠端維運管理。

許多管理員在配置 IPv6 後，經常遇到 IPv4 下 SSH 連線流暢，但換成 IPv6 位址後直接提示連線逾時。此時去反覆執行 Ping 命令其實很難找到根本原因。

遇到 IPv6 22 連接埠不通時，重點應檢查 Linux 系統中sshd服務的監聽策略。許多 Linux 發行版預設的sshd_config配置只監聽了 IPv4 位址（例如僅僅配置了ListenAddress 0.0.0.0），並沒有顯式宣告對 IPv6 位址（ListenAddress ::）進行監聽。

在這種情況下，即便雲端伺服器擁有合法的公網 IPv6 位址且安全群組放行了 22 連接埠，由於系統內部的 SSH 守護行程根本不處理 IPv6 的連線請求，外部透過 IPv6 進行的遠端連線嘗試自然會全部失敗。​

五、IPv6 連接埠測試結果怎麼看？

連接埠測試不是只有「成功」和「失敗」兩種結果，不同錯誤往往對應完全不同的排查方向。

六、為什麼 IPv6 Ping 正常，但連接埠不通？

如果確認 IPv6 位址能夠成功 Ping 通，但指定的業務連接埠（如 80、443、22 等）仍然無法建立連線，問題通常出在服務配置、防火牆策略或網路路由層面。以下是六個最常見的排查方向：

1. 業務服務僅監聽了 IPv4 位址

這是雙棧伺服器上極為普遍且容易被忽視的配置疏漏。伺服器系統層面雖然已經取得了公網 IPv6 位址，但具體的應用程式（如 Nginx、Apache、sshd 等）並沒有開啟對 IPv6 位址的監聽。

例如，Web 伺服器的配置檔案中如果只設定了監聽0.0.0.0:443，這就意味著它僅在 IPv4 的所有介面上接收請求，而沒有建立對應的 IPv6 監聽器。

這種配置會導致非常典型的故障現象：

• IPv4 443 連接埠：正常存取

• IPv6 位址 Ping：回應正常

• IPv6 443 連接埠：連線逾時或被拒絕

此問題與外部電信業者線路無關，根源完全在伺服器內部的服務配置。在 Linux 系統中，可以透過以下命令快速查看連接埠監聽詳情：

ss -lntp

在輸出結果中，重點觀察目標連接埠綁定的是 IPv4 格式（如0.0.0.0:443），還是包含 IPv6 雙棧綁定格式（如[::]:443或:::443）。

2. 雲端伺服器安全群組缺少 IPv6 放行規則

在阿里雲、騰訊雲、AWS 等雲端平台上，安全群組規則通常將 IPv4 與 IPv6 劃分為兩個獨立配置的標籤頁。

不少管理員在部署服務時，完整配置了 IPv4 入站規則（放行 TCP 80、443、22 等），卻忘記在 IPv6 入站規則中新增對應的放行策略。

在這種情況下，即便伺服器擁有合法的公網 IPv6 位址，且 ICMP 流量（Ping）預設被允許，外部發起的 TCP 連接埠建連請求也會在雲端平台的虛擬閘道處被直接攔截。因此，更新雲端伺服器的安全規則時，務必核對 IPv6 入站規則清單。

3. 伺服器系統內部防火牆攔截

除了雲端平台外圍的安全群組之外，伺服器作業系統內部的防火牆同樣會對資料封包進行二次過濾。

Linux 系統中的nftables、iptables/ip6tables，或者 Windows 系統的 Defender 防火牆，都有可能針對 IPv6 流量套用了單獨的規則。

外部請求到達伺服器程式的完整路徑通常為：

用戶端請求 → 雲端平台安全群組 → 系統內部防火牆 → 應用程式監聽連接埠

在這條鏈路中，任何一環設定了過濾策略（DROP 或 REJECT），TCPing 檢測都會宣告失敗。排查時不能僅查看雲端廠商的控制台，還需登入伺服器確認系統內部防火牆的放行狀態。

4. 網域 AAAA 記錄指向錯誤的 IPv6 位址

如果是透過網域測試連接埠連通性，還需要仔細核對 DNS 解析設定。

在雙棧站點中，網域通常同時配置了 A 記錄（指向 IPv4）和 AAAA 記錄（指向 IPv6）。如果 IPv4 的 A 記錄指向無誤，但 AAAA 記錄仍然殘留著舊伺服器、過期節點或錯誤的 IPv6 位址，就會導致 IPv4 存取完全正常，而 IPv6 存取始終逾時。

此時伺服器本身和連接埠配置可能都是正常的，只是用戶端請求被引導到了錯誤的節點上。在測試網域 IPv6 連接埠前，建議先透過dig AAAA example.com或nslookup -type=AAAA example.com查詢實際解析出的位址。

5. CDN、WAF 或反向代理的 IPv6 配置不完整

如果網站前端接入了 CDN 加速、高防 IP 或 WAF 防護，用戶端實際連接的是邊緣節點的 IPv6 位址，而非來源站真實 IP。

資料傳輸過程變為：

使用者用戶端 → IPv6 網路 → CDN/WAF 邊緣節點 → 來源站伺服器

當出現 IPv6 443 連接埠不通時，需要確認 CDN 控制台中是否已開啟 IPv6 支援、邊緣節點的 AAAA 記錄解析是否生效，以及 CDN 到來源站的回源配置是否正常。如果 CDN 邊緣節點未能正確處理 IPv6 連線，就會出現來源站 IPv6 連接埠本身正常，但經過 CDN 代理後反而打不開網站的情況。

6. IPv6 骨幹網路路由或電信業者線路差異

最後一種情況屬於網路傳輸路徑異常。

IPv6 與 IPv4 屬於兩套相對獨立的網路體系，二者所走的骨幹網路路由、跨網互聯節點以及電信業者策略並不完全一致。

如果透過線上多節點 TCPing 測試時，發現類似如下的結果：

• 北京電信：443 連接埠 正常

• 上海聯通：443 連接埠 正常

• 浙江電信：443 連接埠 正常

• 廣州移動：443 連接埠 逾時

• 深圳移動：443 連接埠 逾時

這種局部節點逾時的現象，通常表明伺服器連接埠和安全群組配置是沒有問題的。此時盲目重啟服務或修改防火牆配置往往無濟於事，更合理的方式是藉助多節點檢測工具和 IPv6 Traceroute 路由追蹤，進一步定位資料封包究竟是在哪一級電信業者骨幹網路出現了丟包或路由迴圈。​

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

碰到 IPv6 連接埠無法連線時，不建議一上來就修改伺服器配置。按照固定順序排查，通常會快很多，整個過程可以整理成：

查詢 AAAA 記錄
       ↓
確認 IPv6 位址
       ↓
Ping IPv6
       ↓
測試目標 TCP 連接埠
       ↓
連接埠是否全部節點失敗？
       ↓
 ┌─────┴─────┐
 是           否
 ↓            ↓
檢查伺服器    比對異常地區
 ↓            ↓
服務監聽      IPv6 路由
 ↓            ↓
安全群組      電信業者網路
 ↓
系統防火牆
 ↓
CDN / WAF
 ↓
重新進行多節點測試

首先查詢網域的 AAAA 記錄，確認它是否已經指向正確的 IPv6 位址。

接著測試 IPv6 基礎連通性。如果連 IPv6 位址本身都無法到達，就應該先解決位址設定、IPv6 閘道、路由或電信業者網路問題，而不是直接檢查 Web Server。

如果 Ping 大致正常，再繼續測試真正使用的 TCP 連接埠。例如網站檢查 80 和 443，SSH 檢查 22。

這時候不要只看自己電腦的結果。

如果 Chahu 多節點 TCPing 顯示全國及海外多個節點全部無法連線，可以重點回伺服器檢查服務監聽、安全群組以及系統防火牆；如果大部分節點正常，只有少數地區失敗，則更應該考慮網路路徑和電信業者差異，而不是直接認定連接埠沒有開放。Chahu 目前提供 TCP 連接埠連通性及多節點檢測能力，適合用來做這一層交叉驗證。

如果 TCP 連接埠已經正常建立連線，但瀏覽器依然報錯，則說明問題可能已經越過網路層和傳輸層，需要繼續檢查 TLS、HTTP 狀態、憑證、反向代理以及應用服務。

實際排查時，把這幾層分開往往比反覆修改設定更有效：

DNS
 ↓
IPv6 網路
 ↓
TCP 連接埠
 ↓
TLS
 ↓
HTTP / 應用

在哪一層第一次出現異常，就從哪一層開始繼續查。

結語

IPv6 連接埠測試真正要確認的，並不是伺服器「有沒有 IPv6」，而是使用者透過 IPv6 網路能不能連線到實際使用的業務連接埠。一個 IPv6 位址能夠正常 Ping，只能說明基礎網路在當前測試環境下具備一定的可達性，並不能證明 80、443、22 等 TCP 連接埠已經對外正常開放。

遇到網站 IPv6 打不開、SSH 無法連線或者 API 逾時時，更實用的排查方式是先確認 AAAA 解析，再檢查 IPv6 基礎連通性，隨後透過 TCPing 測試對應業務連接埠。如果單一網路測試正常，還應繼續透過多個地區和電信業者節點進行比對。這樣才能逐步判斷問題到底出在 IPv6 位址、TCP 連接埠、伺服器安全策略、服務監聽，還是某個地區的 IPv6 網路路徑，而不是看到一次 Ping 成功就認為整個 IPv6 服務已經正常。

相關問答

1. 用 nmap 掃 IPv6 連接埠，指令和掃 IPv4 有啥不一樣？

nmap 掃 IPv6 必須加 -6，比如 nmap -6 -p 80,443,22 2001:db8::1。不加 -6 它預設走 IPv4，你掃半天也掃不到。如果目標禁 Ping，加 -Pn 跳過主機發現。但說實話，nmap 掃連接埠容易被雲端業者安全群組或防火牆當掃描行為攔掉，結果不一定準。最好先拿 nc 或 TCPing 手動確認一兩個連接埠，再用 nmap 批次看。

2. 雲端伺服器安全群組加了 IPv6 規則，為什麼連接埠還是不通？

先看規則是不是加在「入方向」，協定選 TCP，連接埠範圍寫對，來源位址別只寫自己的 IP，測試時可以先放 ::/0。很多雲端平台 IPv4 和 IPv6 安全群組是分開的，你改完 IPv4 那套，IPv6 那套沒動，等於沒放行。還要確認執行個體真的分配了公網 IPv6，子網路由也指對了。改完等一兩分鐘再測。

3. Nginx 怎麼設定才能同時監聽 IPv4 和 IPv6 的 443？

在 server 區塊裡寫兩行：listen 443 ssl; 和 listen [::]:443 ssl;。如果想一個監聽同時吃 IPv4 和 IPv6，可以寫 listen [::]:443 ssl ipv6only=off;。改完 nginx -t 測試，再 reload。然後用 ss -lntp | grep 443 看有沒有 [::]:443。只有 0.0.0.0:443 的話，IPv6 肯定連不上。

4. 如何用 curl 指定 IPv6 位址測試 HTTPS，不依賴 DNS？

用 --resolve 直接指定，比如 curl -6 -v --resolve example.com:443:[2001:db8::1] https://example.com。這樣就算 AAAA 記錄沒設好，也能強制走你指定的 IPv6 位址。加 -v 看 TLS 握手和憑證細節。如果連上了但憑證報錯，那是 TLS 層的事，跟連接埠通不通沒關係。

5. IPv6 連接埠測試顯示 timeout，怎麼判斷是防火牆 DROP 還是路由不通？

用 traceroute6 或 mtr -6 看路徑。如果資料包在某一跳之後全是星號，可能是路由黑洞或者中間設備丟包。如果最後一跳已經到目標伺服器了，但連接埠還是 timeout，那大概率是防火牆 DROP。要是 REJECT，通常會回傳 connection refused。不過 ICMPv6 也可能被禁，所以別只靠一種結果下結論。