網站要不要支援IPv6？改造順序與常見坑

行動網路和部分家寬已預設優先走IPv6，只做IPv4的站點在純v6環境下會直接訪問失敗。本文按伺服器、解析、CDN三層給出改造順序，並列出公網直通、應用寫死v4等四個常見坑。

IPv6 的推進節奏這兩年明顯加快，行動網路和不少家庭寬頻已經預設優先走 IPv6。對站長來說，問題不再是“要不要做”，而是“怎麼改才不出亂子”。結論先行：面向公眾訪問的站點值得做，但不必一次性全量切換，先做雙棧，觀察一段時間再推進。 為什麼值得做。一是可達性，純 IPv6 網路下的使用者訪問純 IPv4 站點會直接失敗或走轉換閘道器。二是體驗，主流瀏覽器普遍採用先試 IPv6、失敗回退的策略，雙棧站點在支援 v6 的網路上往往能拿到更短的握手時間。三是不少平臺在逐步要求站點支援 v6，早做比臨時補省事。 改造分三層，順序別亂。 第一層是伺服器。確認主機已經分到 IPv6 地址，Web 服務監聽要覆蓋 v6，比如 nginx 裡寫 listen [::]:443 ssl，只寫 IPv4 的 listen 不會響應 v6 請求。防火牆也要放行 v6，很多“加了解析卻打不開”的情況都卡在這一步。 第二層是域名解析。新增 AAAA 記錄指向伺服器的 v6 地址。建議先把 TTL 調短方便回滾，上線後觀察解析生效情況和錯誤率。 第三層是 CDN 與防護。站點前面如果有 CDN 或高防，要確認它支援雙棧：使用者側能接 v6，回源側走 v4 還是 v6 需要提前對齊。常見問題是前端開了 v6、回源仍用 v4，此時源站必須保留 v4 監聽，否則會出現 502。 幾個容易踩的坑，提前說清楚。 第一個坑是 v6 沒有 NAT。v4 時代很多服務靠內網地址加埠對映，看起來安全；v6 地址通常是公網直通，資料庫、快取、管理面板如果跟著監聽所有地址，等於直接暴露在公網上。 第二個坑是應用裡寫死的 IPv4。白名單、回撥地址、介面的 IP 校驗，都可能只認點分十進位制地址，切換前先搜一遍配置和程式碼。 第三個坑是監控與統計。部分工具按 IPv4 欄位設計，v6 上線後訪問日誌裡可能出現大量未知來源，解析規則要同步調整。 第四個坑是把 v6 當成效能方案。它解決的是地址枯竭與可達性，不解決繞路和丟包。 落地時分兩步走：先在測試域名上跑通雙棧，確認應用無異常，再給主域名加 AAAA 記錄並保留 A 記錄，觀察兩到四周。 如果站點還在選伺服器和解析方案的階段，加速IDC 的雲伺服器與域名服務支援 IPv4/IPv6 雙棧配置，可以一步到位，省去後期回補的麻煩。