IPv6 設定教學：VPS 上啟用雙堆疊的實務細節與常見地雷

打開大部分的 IPv6 設定教學，流程大致都是「編輯 netplan、填入位址、執行 apply」，三分鐘結束。但真的在 VPS 上動手做，會發現坑比想像中多：gateway 不在同一個網段、路由宣告出去卻收不到回應、Docker 容器能連 IPv4 但拿不到 IPv6、或是 AAAA 記錄設定完郵件就開始被退信。這些情境標準教學幾乎不會提到。

這篇 IPv6 設定教學從伺服器端實際會遇到的三種配置類型講起，搭配常見的踩雷情境與對策，幫助真正把 IPv6 跑起來——而不只是讓 ip -6 addr 看起來有東西。

為什麼 VPS 還是應該啟用 IPv6

純粹從「IPv4 不夠用」角度談 IPv6，對臺灣多數使用者沒什麼說服力——取得一個 IPv4 位址的門檻仍然不高。真正的動機有幾個更實際的方向。

一是部分海外使用者是 IPv6-only。行動網路、某些企業內網、以及部分新興國家的家用網路已經全面轉向 IPv6，靠 CGNAT 回退到 IPv4 時體驗會明顯變差。服務只掛在 IPv4 上，這批流量過來幾乎必然是退化的。

二是郵件伺服器的信用評分會因為缺少 IPv6 而被扣分。Gmail、Outlook 等大型服務對外寄信來源的評估項目包含 IPv6 可達性與 PTR 記錄完整性。雙堆疊並正確設定反向解析，比純 IPv4 的 IP 信譽更容易維持。

三是中華電信、TANet 等臺灣主要網路早已原生支援 IPv6，雲端平台、CDN、SaaS 幾乎全數雙堆疊。等到真的出現某個關鍵服務只接受 IPv6 再臨時調整，成本遠高於現在順手加一段設定。

VPS 上 IPv6 的三種配置型態

動手前先釐清上游給了什麼樣的配置。這是多數教學沒講清楚、卻決定後面所有步驟的關鍵。VPS 環境裡最常遇到的是以下三種：

第一種：on-link /64 子網。上游把一整個 /64 放在同一個廣播域上，閘道器也在這個 /64 之內，例如 2001:db8:100::/64，閘道 2001:db8:100::1，VPS 拿到 2001:db8:100::10/64。這是最直觀的配置，跟 IPv4 的邏輯幾乎一樣——設 address、設 gateway、結束。

第二種：/128 加路由前綴。上游只給 VPS 一個單獨的 /128 位址，但會路由一整塊 /64 或 /56 過來讓使用者自行分配給容器、VM 或次要服務。這種配置在多租戶雲端環境更常見，因為每個 VPS 的 NDP 範圍可以被嚴格隔離。設定上需要在介面加上 /128 位址，並為路由過來的前綴加上一條靜態路由。

第三種：gateway 不在子網內。一些上游（例如 Hetzner、部分 BGP-based 的環境）會發 /64 給 VPS 但把閘道器放在一個完全不同的 /64 裡，閘道甚至可能就是個 link-local fe80::1。這種配置在 netplan 裡會報「gateway not in subnet」的錯，必須加上 on-link: true 或明確用 link route 指向閘道。

開工前務必到 VPS 管理面板確認拿到的到底是哪一種，並記下位址、前綴長度、閘道器形式。錯一個字元，後面找原因可能要花一整個下午。

netplan 實例：三種情境的寫法

Ubuntu 18.04 以後的標準是 netplan，配置檔通常在 /etc/netplan/ 底下。下面給出三種情境各自的寫法，假設網路介面叫 ens3。

on-link /64 子網：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      dhcp6: false
      accept-ra: false
      addresses:
        - 2001:db8:100::10/64
      routes:
        - to: "::/0"
          via: "2001:db8:100::1"
      nameservers:
        addresses:
          - 2606:4700:4700::1111
          - 2001:4860:4860::8888

這裡刻意不用 gateway6 欄位，它在新版 netplan 中已被標記為 deprecated，改用 routes 區塊寫法更一致。accept-ra: false 是避免靜態配置下意外收到路由器通告、被 kernel 加上額外的位址或預設路由。

gateway 不在子網內，必須用 on-link：

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 2a01:4f8:abcd::2/64
      routes:
        - to: "2a01:4f8:0:1::1"
          scope: link
        - to: "::/0"
          via: "2a01:4f8:0:1::1"

先用一條 link scope 的路由告訴 kernel「閘道器可直接從介面送達」，再指向它作為預設路由。這個技巧在靜態 IPv6 配置裡非常常用，卻是初次接觸的人最容易卡住的地方。

套用配置前可以先用 netplan try，它會先套用、120 秒內沒確認就回滾，避免配錯把 SSH 鎖死。確認沒問題再用 netplan apply。

防火牆：ip6tables 跟 nftables 的對稱處理

IPv6 最常見的安全事故不是「被攻擊」，而是「管理員忘了把 IPv4 的規則複製到 IPv6」。ufw 會自動處理雙堆疊，但如果使用者是手刻 iptables，iptables 跟 ip6tables 是兩套獨立的規則，漏掉其一等於半邊開門。

IPv6 的 ICMPv6 不能像 IPv4 那樣隨便封掉。Neighbor Discovery（類似 IPv4 的 ARP）、Router Advertisement、Path MTU Discovery 全部走 ICMPv6，封掉會導致連線忽好忽壞、TCP 大封包莫名卡住。改用 nftables 會比較乾淨，一條規則就能涵蓋：

1
2
3

icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert,
              nd-router-advert, echo-request,
              packet-too-big, destination-unreachable } accept

Docker 的 IPv6 設定

Docker 對 IPv6 的支援長期以來是半殘狀態，Docker 24 以後有顯著改善。關鍵是兩個開關：daemon 層級的 ipv6: true 以及 ip6tables: true，分別負責啟用 IPv6 支援跟讓 Docker 接管 IPv6 版的 port publishing 規則。

/etc/docker/daemon.json 建議設定：

{
  "ipv6": true,
  "ip6tables": true,
  "fixed-cidr-v6": "fd00:dead:beef::/48"
}

fixed-cidr-v6 用 ULA（fd00::/8 以下的位址）而不是 public 前綴，因為預設 bridge 網路的容器通常不需要對外曝光 IPv6。要對外直連再透過使用者定義的網路指定 public 前綴即可。發布 port 時 Docker 會同時在 IPv4 與 IPv6 上監聽——這也是為什麼 ip6tables: true 必開，否則 -p 80:80 只會綁到 IPv4，從 IPv6 進來的請求會被拒絕，卻不會有任何錯誤訊息。

AAAA 記錄跟反向解析的常見陷阱

加完 IPv6 位址、防火牆也開了，剩下的環節是 DNS。AAAA 記錄看似只是複製 A 記錄的邏輯，但有個容易被忽略的場景：多台伺服器共用一個域名做負載分攤時，A 跟 AAAA 必須指向同一批伺服器，否則 happy eyeballs 演算法會讓使用者的 IPv4 跟 IPv6 流量落在不同機器上，session affinity 瞬間碎裂。

郵件伺服器尤其敏感。MX 指向的主機若有 AAAA 記錄，Gmail 等接收方會偏好走 IPv6。但 IPv6 這邊若沒設定正確的 PTR 記錄，或 PTR 指向的主機名稱跟寄件識別不一致，郵件會被直接退或丟進垃圾桶。三個檢查點：VPS 面板支援 IPv6 反向解析、PTR 指向的主機名跟 SMTP 宣告的 HELO/EHLO 名稱要一致、該主機名要有對應的 A 跟 AAAA 記錄並指回同一台 VPS。少一個環節，SpamAssassin 就會扣分。

排查 IPv6 郵件問題時，若暫時無法立刻修好，暫時把 MX 主機的 AAAA 記錄移除是比較保險的回退，優於留著半壞的狀態。

幾個典型的排查情境

ping6 google.com 卡住沒反應，但 ping6 2606:4700:4700::1111 正常：DNS 解析沒走 IPv6。檢查 /etc/resolv.conf 或 netplan 的 nameservers 是否包含 IPv6 resolver。

ip -6 addr 看得到位址，ping6 2001:4860:4860::8888 卻 Network is unreachable：預設路由沒建立起來。ip -6 route show 檢查有沒有 default via ...，沒有就是 gateway 或 on-link 設定錯誤。

外部從 IPv6 連不進來，但本機能對外 ping6：Neighbor Discovery 沒正常運作。在 on-link /64 環境下，可以先對外 ping 一次來主動宣告自己的存在；在 routed prefix 環境下，若要讓容器或二級 IP 對外可達，需要啟用 NDP proxy（sysctl net.ipv6.conf.all.proxy_ndp=1 並用 ip -6 neigh add proxy 建立條目）。

Docker 容器能跑但 curl -6 ifconfig.co 失敗：多半是 ip6tables: true 沒開、或 fixed-cidr-v6 用的是 ULA 而對外沒有 NAT66。要讓容器對外用本機 IPv6 出去，要嘛分配 public IPv6 給容器，要嘛設定 NAT66（不推薦，違反 IPv6 設計原則）。

做完這些，IPv6 才算真的跑起來

從配置檔到防火牆、從 Docker 到 DNS，雙堆疊的每個環節都需要單獨檢查。許多人以為 netplan apply 成功、ip -6 addr 看到位址就結束了，結果郵件一直被退、容器跑不出去、或是從 IPv6-only 網路連進來直接 timeout。

有個簡單的自我驗收方式：用手機關掉 Wi-Fi 走行動網路（臺灣三大電信行動網路普遍已提供 IPv6），打開 https://ipv6-test.com 或 test-ipv6.com 測試目標網站，看連線是用 IPv6 還是回退到 IPv4，以及 PMTUD 與 DNS 行為是否正常。這比在伺服器上自己 ping 測試真實得多。

NCSE Network 所有 VPS 方案皆原生支援雙堆疊 IPv6，提供 /64 位址空間與自助式反向解析設定，機房位於臺灣是方電訊，對臺灣本地 IPv6 流量延遲極低。若正在規劃 IPv6 遷移或需要能穩定提供雙堆疊的伺服器環境，可以進一步了解 NCSE Network 的 VPS 服務。