IPv6 Ping 逾時是什麼原因？線上檢測與排查方法

IPv6 Ping 逾時不一定代表網站無法存取，問題可能來自 ICMPv6 限制、AAAA 記錄錯誤、伺服器閘道、IPv6 路由或電信業者互連異常。本文結合線上多節點測試、DNS 查詢與 Traceroute，說明 IPv6 Ping 逾時的判斷與排查方法。

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

網站或伺服器剛設定好 IPv6 後，很多人會先 Ping 一下測試連線品質。如果能正常回傳幾十毫秒的延遲，基本上可以確認網路已具備一定的 IPv6 通訊能力；但如果連續出現「要求逾時」、沒有任何回應，甚至直接顯示 100% 封包遺失，就很容易讓人懷疑 IPv6 設定出了問題。

實際上，IPv6 Ping 逾時並不一定代表網站的 IPv6 已經無法使用。有些伺服器、防火牆或上游網路會限制 ICMPv6 Echo 請求，但 HTTPS 仍然可以正常建立連線；另外也有一些情況確實是 AAAA 記錄設定錯誤、IPv6 預設路由異常、伺服器閘道錯誤或電信業者線路不通。

所以遇到 IPv6 Ping 逾時時，不能只看一次 Ping 結果。更有效的排查思路，是先判斷問題究竟屬於「只有 Ping 不回應」，還是「整個 IPv6 網路都無法存取」，再繼續檢查 DNS、伺服器和網路路徑。

一、IPv6 Ping 逾時是什麼意思？

IPv6 Ping 的底層邏輯和 IPv4 差別不大，都是透過「我發一個請求，你給一個回應」來判斷鏈路是否順暢。不過在 IPv6 環境下，這個過程依賴的是 ICMPv6 協定。

根據 RFC 4443 的規定，ICMPv6 中的 Echo Request 類型為 Type 128，Echo Reply 為 Type 129。除了處理 Ping 之外，ICMPv6 還承擔著目標不可達、封包過大（Packet Too Big）、逾時等非常關鍵的網路控制功能。

一個標準的 IPv6 Ping 互動過程如下：

用戶端/本機電腦 
    └─► 發送 ICMPv6 Echo Request (Type 128)
           └─► 經過 IPv6 骨幹網路與路由器
                  └─► 到達目標伺服器
                         └─► 回傳 ICMPv6 Echo Reply (Type 129)
                                └─► 用戶端收到回應，顯示延遲

如果 Echo Request 發出去之後，在規定時間內沒有收到 Reply，終端就會提示「要求逾時（Request timed out）」。

這裡最容易陷入的誤區，就是把「Ping 逾時」直接和「IPv6 徹底壞了」畫上等號。

Ping 只能表明目前的 ICMPv6 測試封包沒有得到回應。如果伺服器策略禁掉了 Echo 測試，或者中間的流量清洗設備攔截了這部分封包，即使 Ping 顆粒無收，網站的 TCP、HTTPS 流量依然可以完美通行。

遇到逾時的第一件事，不是馬上就去刪 AAAA 記錄，而是先驗證網站在 IPv6 下到底還能不能正常開啟。

二、IPv6 Ping 逾時最常見的原因有哪些？

造成 IPv6 Ping 逾時的情況很多，但實際維運中最常碰到的，基本集中在下面幾類。

1. 目前網路本身沒有正常的 IPv6 連線能力

先不要急著懷疑伺服器。如果你在自己的電腦上測試任何公網 IPv6 位址都會逾時，問題很可能出在目前的接取網路，而不是目標網站。

有些裝置雖然能夠看到類似：

fe80::xxxx:xxxx:xxxx:xxxx

這樣的位址，但fe80::/10屬於 IPv6 連結本地位址，只能用於本機鏈路通訊，不能說明裝置已經取得了完整的公網 IPv6 存取能力。

真正能夠正常存取網際網路，還需要正確的 IPv6 位址、預設路由、閘道以及電信業者 IPv6 網路支援。

因此，如果只有自己電腦 Ping 不通，而其他地區測試正常，優先檢查本機網路會比直接修改伺服器設定更合理。

2. 網域的 AAAA 記錄設定錯誤

如果測試的是網域，DNS 記錄必須重點檢查。IPv4 用的是 A 記錄，IPv6 用的則是 AAAA 記錄。

A 記錄：example.com -> 203.0.113.10
AAAA 記錄：example.com -> 2001:db8::10

如果伺服器更換過 IPv6 位址，或者在設定 DNS 時手滑輸錯了一個字元，使用者解析到的就會是一個無效或舊的 IPv6 位址，直接導致 IPv6 存取失敗並持續逾時。

3. 伺服器有 IPv6 位址，但預設路由或閘道錯誤

這是在 Linux 伺服器上手動設定 IPv6 時極易踩坑的地方。

你登入伺服器執行ip addr，確實能看到網卡上掛著一個漂亮的公網 IPv6 位址，看起來一切正常。但如果沒有設定 IPv6 預設路由，或者閘道 IP 寫錯了，就會出現「封包能進來，但回應發不出去」的尷尬局面。在外邊看來，自然就是一连串的逾時。

4. 防火牆或安全群組限制了 ICMPv6

如果網站能秒開，但怎麼 Ping 都逾時，90% 的機率是安全策略的問題。需要檢查的層級包括：

雲端業者主控台的安全群組規則
Linux 本身的iptables/nftables/firewalld
Windows Firewall
硬體防火牆與防護節點

這裡順便提個醒：不要為了安全把 ICMPv6 粗暴地全部封死。IPv6 非常依賴 ICMPv6 來做路徑 MTU 探索（PMTU）等網路協商，全禁掉可能會導致某些大封包直接掛掉。正確的做法是僅按需限制 Echo Request（Type 128），或者設定合理的放行規則。

5. IPv6 電信業者路由或互連存在異常

如果測試結果不是全國全部失敗，而是類似：

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

這時候伺服器本身完全無法使用的可能性反而下降了。

因為如果目標 IPv6 位址徹底不可達，通常不會只有一家電信業者或幾個地區持續失敗。

這種局部異常更值得檢查：電信業者 IPv6 互連、區域路由、BGP 路徑或上游網路。

例如移動存取目標 IPv6 網路走了一條異常路徑，而電信和聯通使用另一條線路，就可能造成兩邊表現完全不同。這也是為什麼 IPv6 Ping 逾時不能只在自己電腦上測一次。

6. CDN 的 IPv4 和 IPv6 節點狀態不同

如果網站掛了 CDN，情況會稍微複雜一點。CDN 業者在不同地區的節點部署進度和線路品質可能有差異。可能 IPv4 走的是節點 A，IPv6 走的是節點 B。一旦某個區域的 IPv6 邊緣節點故障，就會導致該地區的 IPv6 Ping 逾時或存取異常。

三、先用 Chahu 判斷是「全部逾時」還是「部分地區逾時」

碰到 IPv6 Ping 逾時，我一般不建議第一步就在伺服器上改防火牆或者刪除 AAAA。

先把故障範圍弄清楚更重要。透過 Chahu 的 IPv6 網站測速從不同地區測試目標網站。目前頁面可以按照中國電信、中國聯通、中國移動以及港澳台、海外網路查看結果，並顯示回應 IP、HTTP 狀態、總耗時、DNS 解析、連線和下載時間。

例如測試以後發現：

測試結果	初步判斷方向
多數 IPv6 節點全部失敗	伺服器、AAAA、閘道或上游網路
只有部分地區失敗	區域 IPv6 路由
只有某一家電信業者失敗	電信業者互連或 BGP 路由
Ping 逾時但 IPv6 網站正常	ICMPv6 過濾或限速
Ping 和網站存取同時失敗	IPv6 連線能力本身存在問題
偶爾成功、偶爾逾時	鏈路封包遺失或網路波動

這裡最重要的不是「到底有多少毫秒」，而是先回答一個問題：

問題是全國性的，還是局部性的？

比如：

北京電信      正常
上海聯通      正常
浙江電信      正常
廣州移動      存取失敗
深圳移動      存取失敗

如果只有移動網路出現問題，那麼繼續反覆檢查伺服器 IPv6 位址的價值已經不大，下一步更應該關注移動 IPv6 到目標網路之間的路由。

反過來，如果所有地區都無法透過 IPv6 存取，則伺服器、AAAA、閘道、防火牆或上游 IPv6 網路就應該優先檢查。

這種「先縮小範圍，再定位原因」的思路，通常比只在本地執行幾十次 Ping 更有效。

四、Ping 逾時後，先看看 IPv6 網站還能不能正常存取

這是定位問題性質最關鍵的分水嶺。當你在線上工具裡看到封包遺失率 100% 時，接著看一眼 HTTP/HTTPS 的測試狀態。

IPv6 測試結果分支排查：

                   ┌──► HTTP/HTTPS 能正常開啟 (200 OK) ──► 檢查 ICMPv6 防火牆/安全群組過濾策略
                   │
IPv6 Ping 連續逾時 ─┤
                   │
                   └──► HTTP/HTTPS 也建立失敗/逾時 ──► 檢查 AAAA 解析、伺服器 IPv6 及預設路由

情況 A：Ping 逾時，但 HTTPS 秒開、狀態碼 200 這表明 IPv6 基礎網路和業務層都非常穩定。純粹是目標伺服器、CDN 或中間節點把 ICMP Echo 給攔截了。只要業務正常，這種逾時完全不需要焦慮。
情況 B：Ping 逾時，且 HTTPS 拒絕連線或打不開 這才是真正的網路不通。說明封包根本沒有成功建立 TCP 三次握手，需要順著 DNS -> 伺服器 -> 路由網路繼續排查。

Chahu 的 IPv6 網站測速可以直接展示解析時間、連線時間和 HTTP 返回碼，一次測試就能同時完成 Ping 與 Web 業務的對比判斷。

五、再檢查網域的 AAAA 記錄有沒有問題

確認業務確實不通後，排查的第一站回退到 DNS 解析。

用 Chahu 的 DNS 查詢 功能，檢查全國各地遞迴 DNS 返回的 AAAA 記錄。重點梳理以下四點：

是否有 AAAA 記錄：網域是否根本沒加 IPv6 解析？
位址是否相符：AAAA 解析出來的 IPv6 位址，和伺服器上實際綁定的公網 IPv6 位址是否完全一致？
是否殘留舊 IP：伺服器更換過 IPv6 後，TTL 還沒到期，導致部分地區依然解析到舊的廢棄 IP。
多線路解析一致性：檢查電信、聯通、移動解析出來的 IP 是否符合預期（特別是在設定了智慧 DNS 或 CDN 的情況下）。

如果發現移動線路解析出來的是一個已經失效的 IPv6 位址，那直接去 DNS 服務商後台把記錄修正過來，問題就迎刃而解了。

六、AAAA 沒問題，再用 Traceroute 看封包停在哪裡

如果 DNS 回傳正確，伺服器 IPv6 位址也確認無誤，但網站仍然無法透過 IPv6 存取，就需要繼續看網路路徑。

Windows 可以執行：

tracert -6 example.com

Linux 常見方式是：

traceroute -6 example.com

正常情況下，可以看到封包逐跳向目標網路靠近。

例如：

1   本地 IPv6 閘道      2ms
2   電信業者網路          6ms
3   IPv6 骨幹網路        12ms
4   上游網路           25ms
5   目標伺服器         31ms

如果變成：

1   本地 IPv6 閘道      2ms
2   電信業者網路          7ms
3   IPv6 骨幹網路        15ms
4   * * *
5   * * *
6   * * *

就需要繼續判斷異常是不是從第四跳之後開始出現。不過這裡也不要看到一個*就馬上認為線路斷了。很多路由設備本身就不會回應 Traceroute 的探測封包，可能出現：

1   正常
2   * * *
3   正常
4   正常
5   目標伺服器

這種線路實際上仍然可以正常通訊。

真正值得關注的是：從某個位置開始，後續所有路徑都無法繼續，並且實際 IPv6 網站存取也同時失敗。

如果這種現象只發生在某一家電信業者，再結合其他電信業者的正常路徑進行比較，通常就能進一步判斷問題發生在哪段互連網路。

七、不同測試現象分別應該查哪裡？

排查到這裡，其實已經不需要把所有設定重新檢查一遍。

根據現象縮小範圍會快很多：

實際現象	優先排查方向
自己存取任何 IPv6 都失敗	本地網路、路由器、電信業者 IPv6
所有地區都失敗	伺服器 IPv6、AAAA、閘道、上游路由
IPv4 正常，IPv6 全部失敗	IPv6 位址與網路設定
IPv6 Ping 逾時，但 HTTPS 正常	ICMPv6 防火牆或限速
只有部分地區失敗	區域路由或 CDN IPv6 節點
只有某個電信業者失敗	電信業者 IPv6 互連
AAAA 指向錯誤 IPv6	DNS 設定
Ping 偶發逾時並伴隨封包遺失	網路抖動、壅塞或路由波動
Traceroute 從某段開始全部中斷	上游路由或互連鏈路

八、IPv6 Ping 逾時應該按什麼順序排查？

如果只是偶爾遇到一次 IPv6 逾時，可以重新測試幾次觀察是否屬於短暫波動。

如果問題持續存在，我更建議按下面這個順序走：

發現 IPv6 Ping 逾時
          ↓
確認本地是否擁有正常 IPv6 連通性
          ↓
使用多節點測試擴大觀察範圍
          ↓
判斷全部節點失敗還是部分節點失敗
          ↓
測試 IPv6 網站是否還能正常存取
          ↓
檢查 AAAA 解析結果
          ↓
確認伺服器 IPv6 位址
          ↓
檢查 IPv6 預設路由和閘道
          ↓
檢查安全群組 / 防火牆 ICMPv6 策略
          ↓
Traceroute 比較網路路徑
          ↓
定位 CDN / 電信業者 / BGP 路由異常

從影響範圍大的地方開始判斷，再逐步往具體設定收縮：如果全國幾十個節點都失敗，重點查伺服器側；如果只有兩三個地區失敗，重點查網路路徑；如果網站能夠正常透過 IPv6 開啟，只是 Ping 不回應，重點查 ICMPv6。這樣排查下來，基本不會在錯誤的方向上浪費太多時間。

IPv6 Ping 逾時只能說明當前測試沒有收到正常的 ICMPv6 Echo Reply，並不能單獨證明整個 IPv6 網站已經無法存取。真正排查時，先透過不同地區和電信業者判斷問題範圍，再看 IPv6 網站是否能夠正常建立連線。如果 Ping 逾時但 HTTPS 正常，重點檢查 ICMPv6 過濾策略；如果 Ping 和網站存取都失敗，則繼續檢查 AAAA、伺服器 IPv6 位址、預設閘道和上游路由。而當問題只集中在某些地區或某一家電信業者時，就不要一直圍著伺服器設定打轉。結合多節點測試和 Traceroute 查看實際路徑，往往更容易找到真正異常的那一段網路。