在純 IPv6 伺服器上能用 GitHub 嗎？

不能直接用。在我們 2026 年 9 月的檢查中，github.com、api.github.com、objects.githubusercontent.com（發行版下載）和 ghcr.io 都沒有發布 IPv6 位址，所以 git clone、API 以及從 GitHub 拉取容器都會失敗。raw.githubusercontent.com 則有 IPv6。

能在純 IPv6 上執行 Discord 機器人嗎？

不能：在我們的檢查中，discord.com 和 Discord 閘道都沒有 IPv6 位址。Telegram 機器人沒問題：api.telegram.org 支援 IPv6 回應。

為什麼純 IPv6 伺服器更便宜？

IPv4 位址稀缺，每個月都讓服務供應商付出真金白銀；IPv6 位址幾乎是免費的。純 IPv6 方案把這部分節省讓給您，代價是所有隻支援 IPv4 的東西都用不了。

如何檢查某個服務是否支援 IPv6？

執行 'dig +short AAAA hostname'。沒有輸出就說明沒有 IPv6 位址。在雙棧機器上，'curl -6 -sI https://hostname' 可以確認它確實能透過 IPv6 回應。

EQVPS 賣純 IPv6 方案嗎？

不賣。EQVPS 的所有方案都透過 IPv4 存取網際網路：NAT 方案經由 NAT 出網，您透過專屬 SSH 埠登入；獨立方案擁有自己的公用 IPv4。NAT 方案每月 $3 起，足以滿足低預算的需求，又沒有純 IPv6 的麻煩。

純 IPv6 VPS：2026 年哪些能用、哪些會出問題

純 IPv6 伺服器便宜的原因很簡單：IPv4 位址稀缺，每個月都要花錢，而 IPv6 位址不用。所以問題不在於純 IPv6 是否更便宜（確實更便宜），而在於您真正用到的東西還能不能用。我們沒有照搬一年前的論壇答案，而是在 2026 年 9 月親自做了檢查。

我們測了什麼，結果如何

我們查詢了一台典型伺服器在第一天就會用到的各項服務的 IPv6（AAAA）記錄。沒有 AAAA 記錄，就意味著純 IPv6 機器在沒有外力幫助時無法存取它們。

服務	截至 2026 年 9 月 26 日的 IPv6
github.com、api.github.com	❌ 無
objects.githubusercontent.com（發行版下載）	❌ 無
ghcr.io（GitHub 容器映像儲存庫）	❌ 無
raw.githubusercontent.com	✅ 有
Docker Hub（registry-1.docker.io）	✅ 有
PyPI、npm、crates.io、Go 模組代理	✅ 有
Debian / Ubuntu / Alpine 套件來源映像	✅ 有
GitLab	✅ 有
Let's Encrypt（ACME）	✅ 有
Telegram Bot API	✅ 有
discord.com 和 Discord 閘道	❌ 無
OpenAI、Anthropic、Google Gemini 的 API	✅ 有
Hugging Face（網站）	✅ 有，但大檔案 CDN 主機：❌ 無
ollama.com	❌ 無（registry.ollama.ai：✅ 有）
Binance API	❌ 無
Coinbase API	✅ 有

規律是：套件管理器、大型 AI 介面和 Telegram 都已就緒。而幾乎每台伺服器都需要的 GitHub，至今仍未就緒。

實際意味著什麼

在純 IPv6 的 VPS 上，您正好會在這些地方碰壁：

git clone https://github.com/... 會失敗。 用 curl 下載 GitHub 發行版的安裝指令碼，以及所有從 ghcr.io 拉取映像的操作也一樣。
Discord 機器人根本連不上閘道。
部分模型下載會中斷：在我們的檢查中，Hugging Face 的大檔案主機和 ollama.com 都沒有 IPv6。
在只支援 IPv4 的交易所上執行的加密貨幣機器人無法存取 API。

對內方向還有一個更隱蔽的問題：只有 IPv4 網路的訪客無法存取託管在純 IPv6 伺服器上的網站，除非您在前面放一個支援 IPv4 的代理或 CDN。

兩秒鐘偵測任意服務

dig +short AAAA github.com          # empty output = no IPv6
dig +short AAAA api.telegram.org    # addresses = IPv6 available
curl -6 -sI https://pypi.org | head -1   # on a dual-stack box: proves it answers over v6

在選擇方案之前，對您的專案要通訊的所有服務都跑一遍。

變通辦法及其代價

NAT64/DNS64。 閘道把 IPv6 請求轉換為發往 IPv4 目標的請求。有公共的可用，但您的流量要經過別人的機器，還得依賴對方的穩定性。
映像和代理。 把 GitHub 儲存庫映像到 GitLab，把映像推到 Docker Hub，在雙棧機器上跑一個小代理。可行，但這是一套您得一直維護的「管道」。
前置 CDN，用於對內 Web 流量，讓 IPv4 訪客也能存取到您。

每一種辦法單獨看都不錯。加在一起，就把純 IPv6 方案省下的那幾美元吃光了。

什麼時候真的需要 IPv4，需要哪一種

對大多數專案來說，實話是：您需要的是 IPv4 連通性，但不一定需要一個屬於自己的 IPv4 位址。

如果沒有任何東西需要連入您的伺服器（機器人、代理、worker、定時任務），NAT 方案就夠了。它能透過 NAT 存取任何服務，包括只支援 IPv4 的那些，您則透過專屬 SSH 埠登入。這是省錢的選擇：NAT 方案每月 $3 起。
如果有東西必須從外部連入（網站、郵件伺服器、遊戲伺服器、VPN 端點），請選擇帶獨立 IPv4 的方案。

我們不賣純 IPv6 方案，原因正是上表所示：每月 $3 就能買到完整 IPv4 連通性的 NAT，為了省這點錢去換一台連 GitHub 都克隆不了的伺服器並不划算。還不確定自己需要哪一種？這裡有一個只需回答一個問題的測試。