全球 IPv4 耗盡：開始計費，開發者遷移受阻，稱 IPv6「難用且無直觀收益」
IPv4 進入“付費時代”
去年的 7 月，Amazon Web Services 宣布自 2024 年 2 月 1 日 起，所有公有 IPv4 將按 $0.005/小時（約 $4/月）計費，無論是否綁定到具體服務；
容器化部署平臺 Fly.io 隨后也在社區公告中更新：2 月 1 日后，每個專用 IPv4 約 $2/月；
開源數據處理與后端平臺 Supabase 計劃推出 IPv4 付費附加包，**$4/月**。
隨著時間逼近，關于「IPv4 付費、向 IPv6 遷移」的討論驟然升溫。
近期，Supabase 聯合創始人兼 CEO Paul Copplestone 發起號召：“準備好，IPv6 要來了。”然而，由于 IPv4/IPv6 首部差異巨大、互不兼容，升級之路困難重重。即便一些開發者嘗試上手，結論卻是：“IPv6 很糟糕”——至少在當前生態與工具鏈支持不足的情況下如此。
1.全球 IPv4 余量見底，IPv6 走到聚光燈下
隨著互聯網終端迅猛增長，RIPE NCC（負責英國、歐洲、中東及部分中亞的互聯網資源分配）在 2019 年 11 月 25 日 15:35（UTC+1） 宣布：最后的 IPv4 地址儲備池已耗盡。全球 約 42 億 個 IPv4 地址已全部分配。
自此之后，想繼續使用公有 IPv4 的用戶，主要依賴回收與再分配：來源要么是已注銷的機構，要么是完成 IPv6 遷移而釋放出來的地址段。
獲取成本隨稀缺性自然攀升。AWS 曾披露：過去五年中，單個公有 IPv4 的收購成本上漲超過 300%——難找又昂貴。 因此，多家云廠商開始按地址收費，一方面倒逼用戶提高使用效率，另一方面也推動行業轉向 IPv6。
Paul Copplestone 指出：“**$4/月** 對個人看似不多，但 AWS 是很多基礎設施公司的底層。以 Supabase 為例，我們為每個 Postgres 數據庫提供獨立 EC2 實例，這項變更會讓我們的 AWS 賬單增加到百萬級。”
也有分析認為：大型 AWS 客戶可能幾乎感覺不到這筆錢；但中小企業與初創團隊則不然，這筆費用**很容易占到總賬單的 10%–30%**。
2.三條應對路徑
面對新增成本，企業如何盡量降低支出？Paul Copplestone 給出了 三種選擇：
- 把成本轉嫁給客戶：與 AWS、Fly.io 的做法類似，調整定價，將租用/購入 IPv4 的開銷體現在產品價格中。以單個 IPv4 為例，**43.80/年**。
- 提供替代方案（如代理/NAT）：比如提供 IPv4 代理，通過代理將 IPv6 流量映射到 IPv4 資源；或利用 NAT 提高 IPv4 地址利用率——一地址多端口區分不同服務/用戶。
- 只提供 IPv6：寄希望于生態盡快跟上、用戶端與鏈路端快速適配。
3.IPv6 推廣的核心難題
從長期看，“僅 IPv6” 最干脆、也最能從根上緩解地址稀缺。IPv6 作為繼任者，對移動設備支持更好、地址分配靈活、首部更簡化、安全性也有所提升。
尤其是地址空間：IPv6 約 3.4×103? 個地址——常被打趣為“每一粒沙子都能分到一個地址”。與 IPv4 相比，規模天差地別，足以覆蓋面向未來的連接增長。
然而，現實有點“骨感”。據 Google 統計，截至 2024 年 1 月 15 日，**IPv6 使用占比僅 41.23%**，距離過半仍有差距。
Paul 將原因主要歸結為兩點：
- ISP（運營商）支持不足；
- 工具鏈支持欠缺。
4.運營商支持不充分
“你的寬帶/移動運營商支持 IPv6 嗎？”
在域名解析層面，傳統上域名會解析到 IPv4：example.com → 93.184.216.34而轉向 IPv6 后，則會解析到 IPv6：example.com → 2607:f8b0:4006:819::200e。
ISP 需要把流量路由到正確目的地。但許多運營商尚未準備充分：交換機/軟件需升級、IPv4/IPv6 互通要打通，這些都意味著投入，而在過去十年里，投入的性價比并未被廣泛認可。
如果 ISP 不支持 IPv6，當域名/服務開始優先解析 IPv6 時，可能出現如下影響與報錯：
- 在 AWS 上架了 Web 服務器，卻無法通過 SSH 連接；
- 從本地直連 Supabase 數據庫時，需要用連接池來回落至 IPv4（供應商要為這些 IPv4 買單）；
- 從 Vercel 連接到任一 AWS 服務器，若未配置 IPv4，連接會迅速失敗。
5.工具鏈支持缺位
不少開發工具尚未對 IPv6 做好準備。以 Supabase 為例，想讓數據團隊的工具鏈 完整支持 IPv6，需要逐步改造：
- VPC 網絡 增加 IPv6；
- Airflow 虛機 增加 IPv6；
- Docker 與 Compose 開啟 IPv6。
看似幾步，但實際落地并不省心。以 Docker 為例，常見流程：
- 修改
/etc/docker/daemon.json：
"ipv6": true,
"fixed-cidr-v6": "fd00:ffff::/80",
"ip6tables": true,
"experimental": true- 重啟 Docker：
systemctl restart docker - 建臨時 IPv6 網絡并測試：
docker network create --ipv6 --subnet fd00:ffff::/80 ip6net
docker run --rm -it --network ip6net busybox ping6 google.com -c3- 檢查
ip6tables（FORWARD）：ip6tables -L - 在 Compose 中開啟 IPv6：
networks:
default:
enable_ipv6: true
ipam:
config:
- subnet: fd00:c16a:601e::/80
gateway: fd00:c16a:601e::1- 進入容器驗證：
docker exec -it "airflow_airflow-worker_1" bash
curl -6 https://ifconfig.co/ip對于如 Docker 這類“標配工具”，這套配置仍顯復雜且易踩坑。
6.邁向 IPv6：現實處處是坎
在實操層面，DevOps 工程師 Mathew Duggan 的經歷頗具代表性：
“幾乎沒有任何東西能 out-of-the-box 地直接跑起來。關鍵依賴立刻失效，臨時方案也不足以支撐生產。我們之所以如此艱難，是因為做這件事的人太少、經驗稀缺；多年沒做，現在只能補課。”
他嘗試將個人博客（https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/）接入 IPv6，并用 CDN 管理 IPv4 流量。
“起步看起來很簡單。我在 Debian 上選了 ‘IPv6’，結果第一個驚喜是：設備沒有拿到單個 IPv6 地址，而是拿到一個 /64（
18,446,744,073,709,551,616）。好消息是：我這臺小小的 ARM 服務器，理論上能跑下我工作過的所有公司的公網網絡基礎設施。”
但把它當“常規服務器”來配，很快就遇到一串問題。
問題 1：SSH 登不上由于工作/家庭 ISP 不支持 IPv6，他不得不先掛上 IPv4，用 SSH 登進去，再用 Cloudflared 跑隧道。 然而 Cloudflare 默認并不會自動做雙棧轉換；去掉 IPv4 后，隧道直接崩。 他只好修改 systemd 服務配置，給 Cloudflared 增加 --edge-ip-version 6，隧道才正常，SSH 也恢復可用。
問題 2：GitHub 用不了
他執行服務器初始化腳本時，腳本需要從 GitHub 拉取 hishtory 的安裝文件，卻一直失敗。 “這不可能吧，GitHub 總該支持 IPv6 吧？” 現實是——GitHub 仍未對外提供完整的 IPv6 支持。 他轉而使用 TransIP Github proxy 才繞過去；但隨后 Python 又報 urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>。
“算了吧，估計 Debian 上的 Python 3 對 IPv6 有點挑，我現在不想再深挖了。”
問題 3：Datadog 裝不起來接著他安裝 Datadog 做監控：登錄、操作，系統立刻崩潰。 他用的是：curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh。既然 S3 已支持 IPv6，那問題在哪？ 排查后，確認既不是 S3 也不是服務器，因為 AWS 的 S3 連通性測試一切正常。最后他只能通過 apt 手工修復。 此時他意識到：純 IPv6 的道路不現實；沒有代理與額外“打補丁”，幾乎什么都跑不順。 后來，為了讓 IPv6 端能訪問 IPv4 資源，他接入了 NAT64（https://nat64.net/）做過渡。
此外，他搜羅的一些輔助工具幾乎都年久失修：Dresel 列表里的若干鏈接不可用；Trex 測試有問題；August Internet 直接“消失”；多數 Go5lab 測試設備離線；Tuxis 能用但貌似自 2019 年 上線后幾乎沒再升級；Kasper Dupont 的服務則仍在維持。
7.IPv6 普及：任重而道遠
雖然時間節點已到，但大量基礎設施與軟件仍未為 IPv6 做好準備。 對于數字從業者而言，培訓與演練會是一項長期投入。
不少開發者表達了相同的挫敗感，HN 用戶的聲音頗具代表性：
“我至今還在抱怨：IPv6 設計為何不向下兼容 IPv4。IPv6 的技術設計確實先進，但缺乏兼容性讓遷移變得異常艱難。設計者或許以為過渡只需幾年，可已近 30 年……我們仍困在這里。”
“在 IPv6 未成為一等公民 之前，它并不能真正解決地址枯竭；只有當我們不再依賴 IPv4 時，這個問題才算畫上句號。”
“如果不遷 IPv6，繼續抱著 IPv4，不僅無法滿足增長需求，還會引發性能下滑與服務不穩定。很多組織被迫用 NAT 分享有限 IPv4，這加大了網絡管理復雜度，也可能限制某些應用/服務的功能。”
正因如此，越來越多的組織加入了 IPv6 遷移 的隊伍——盡管路途崎嶇。
總結
- 短期成本：IPv4 計費已成定局，預算應單列并量化到服務維度；
- 中期策略：優先落實 NAT/代理 與 雙棧過渡，對外暴露盡量少量 IPv4 + 統一代理出口；
- 長期方向：分階段推進 純 IPv6 能力（VPC、容器網絡、CI/CD、監控/日志），建立遷移檢查清單與回退預案；
- 工具與依賴：對關鍵第三方（GitHub、監控、對象存儲、CDN）逐一驗證 IPv6 連通性 與 客戶端支持，必要時準備 NAT64 / 代理 方案；
- 運營商協同：與 ISP 明確升級時間表與互通方案，避免解析策略調整后鏈路斷檔；
- 可觀測性建設：在過渡期提升對 DNS 解析、雙棧握手、連接失敗 的觀測與告警，縮短故障定位時間。
就現在而言，“能跑、穩跑” 仍需依賴雙棧與過渡技術；而 “全棧 IPv6” 則是一個必須投入、但需要耐心的系統工程。當生態真正補齊，IPv6 的價值才會被充分釋放。
