過去很多站長把 IPv6 當成「以後再說」的事。但隨著 IPv4 位址租賃與購買成本持續走高，獨立 IPv4 越來越像一項需要單獨付費的稀缺資源，而 IPv6 位址幾乎不受此限制。2026 年，認真做好 IPv6 支援，已經從技術潔癖變成了實際的成本與可達性問題。

為什麼現在值得動手

  • 成本結構在變：IPv4 越貴，「多綁幾個獨立 IPv4」的老做法就越不划算，而 IPv6 位址充裕。
  • 使用者端早已就緒：主流行動網路和家庭寬頻大量下發 IPv6，純 IPv6 或 IPv6 優先的用戶端佔比逐年上升。
  • 可達性與體驗：對已啟用 IPv6 的使用者，雙堆疊往往能減少一層電信業者級 NAT，鏈路更直接。

建議做法：雙堆疊，而不是激進切換

現階段最穩妥的策略是雙堆疊（Dual-Stack）：同時保留 IPv4 和 IPv6，兩邊都能存取。純 IPv6 部署雖然成本誘人，但你會立刻遇到「只有 IPv4 的第三方 API 呼叫不通」「部分老網路的使用者存取不了」等現實問題，通常需要額外的轉換閘道兜底。對絕大多數業務，雙堆疊是收益與風險最平衡的選擇。

落地步驟

  • 確認伺服器已分配 IPv6 並設定好：檢查網卡是否拿到全球單播位址，預設路由是否正確，能否 ping 通外部 IPv6 位址。
  • 補齊 DNS 的 AAAA 記錄：這是最容易被漏掉的一步。只有 A 記錄，IPv6 使用者依然只能走 IPv4。
  • 讓服務真正監聽 IPv6：Nginx 需要明確加上 listen [::]:443 ssl;，很多應用預設只繫結 0.0.0.0，改成雙堆疊監聽才生效。
  • 防火牆規則要同步：這是最常見也最危險的坑——iptables 的規則不會自動套用到 IPv6，必須同時設定 ip6tables（或使用 nftables／ufw 的雙堆疊規則），否則你精心設定的防護在 IPv6 上等於形同虛設。
  • 核對應用層邏輯：IP 白名單、頻率限制、日誌分析、地理定位等按 IP 處理的功能，都要確認能正確解析 IPv6 格式的位址。

驗證別只靠自己的網路

本機測試通過不代表外部可達。用第三方線上工具做 IPv6 連通性檢查，確認 AAAA 解析、TLS 交握和頁面載入在純 IPv6 環境下都正常，再上線。

SharkCloud 各地區執行個體支援標準的網路設定與獨立 IP 分配，按上述步驟即可完成雙堆疊上線，在 IPv4 成本走高的週期裡保持業務的可達性與彈性。