本文重點：中華電信 HiNet 用戶晚上開 X 圖片、Twitch 或下載 GitHub 檔案變慢，原因指向 HiNet 連往 Fastly CDN 的線路。本文整理 Cloudflare WARP、修改 hosts、強制走 IPv6 三種改善方法，並附上我在 2026 年 10 月的實測數據。
2026 年 10 月有不少中華電信 HiNet 用戶在晚上遇到同一個怪現象：X（推特）的文字打得開，圖片和影片卻一直轉圈，幾乎無法打開或正常顯示；Twitch 偶爾載入緩慢，有時連首頁都打不開；從 GitHub 下載檔案只剩幾十 KB/s。奇怪的是，跑網路測速服務速度完全正常，其他網站不會延遲或卡頓，就連把 DNS 換成 1.1.1.1 或 8.8.8.8 都沒有幫助。
目前網路上看到的多位技術作者與網友的分析結果都指向同一處：中華電信 HiNet 連往 Fastly CDN 的海外連線，X 的圖片與影片、Twitch 和 GitHub 的下載檔案，剛好都有放在 Fastly 上，所以會一起變慢。截至本文撰寫時，我沒有查到中華電信或 Fastly 對這件事的公開說明。
這篇文章整理三種改善方法，從最簡單到最進階：Cloudflare WARP、修改 hosts、強制走 IPv6。
中華電信晚上 X 圖片、GitHub 為什麼會卡？
問題出在封包傳送的路線，網路速度本身正常。根據 HackMD 上的實測分析，同樣是 HiNet 固網，只有 IPv4 連到 Fastly 這一段有嚴重掉包，改走 IPv6 或換用其他電信業者的網路都正常。electrify.tw 的分析則指出，HiNet 前往 Fastly 的流量會繞經 PCCW 與香港，所以延遲與速度都出現異常。
另外可以參考的背景是，Cloudflare 在 2016 年的一篇文章曾估算各地的頻寬成本，指出台北與首爾由強勢的既有業者主導，轉接成本是歐美的 15 倍，並把包含 HiNet 在內的六家業者列為昂貴的網路。這是 Cloudflare 自己的估計，距今已有 10 年，文章也沒有提到 Fastly。我個人推測，這樣的互連環境可能是台灣連外線路容易壅塞的原因之一，但目前沒有公開資料可以證實。
我自己在 2026 年 10 月 7 日晚上 10 點 40 分左右，用 curl 在中華電信光纖（300/300 Mbps）上實測，也看到類似的現象：連到 Fastly 的 X 圖片，連線與首包時間都很正常，但一張約 818 KB 的圖片要下載超過 15 秒，速度只有約 50 KB/s，而且 5 次測試中有 2 次在建立連線時多等了 1 秒以上，符合封包重傳的特徵。
GitHub 下載同樣只有約 40 KB/s，20 秒連一個 64.5 MB 的檔案都下載不完。相較之下，Twitch 的網頁與縮圖在我的環境多半 3 秒內就載入完成，影響比較輕微，但我有遇到首頁一樣打不開的問題，至於直播影片方面倒是沒有問題。
受影響的服務與對應的有效做法如下：
| 服務 | 常見症狀 | 有效的方法 |
|---|---|---|
| X（圖片、影片） | 文字正常，圖片影片一直轉圈 | WARP、修改 hosts |
| Twitch | 網頁與縮圖偶爾變慢（我的環境影響較輕微） | WARP |
| GitHub | 下載檔案只有幾十 KB/s | WARP、強制走 IPv6 |
三種方法怎麼選
三種方法的適用對象與優缺點整理如下：
| 方法與適合對象 | 優點 | 缺點 |
|---|---|---|
| Cloudflare WARP 所有人，尤其是需要下載 GitHub 檔案的人 | 免費、裝 App 開關即可，三個服務一次改善 | 全部流量都會繞道，可能影響其他網站的速度，部分網站可能對 VPN 類 IP 風控 |
| 修改 hosts 只想改善 X 圖片與影片，不想開 VPN 的人 | 不影響其他流量 | IP 之後可能失效，手機無法直接改，開 VPN 時無效 |
| 強制走 IPv6 熟悉路由器或 DNS 設定的進階用戶 | 直接避開有問題的 IPv4 路線，GitHub 速度大幅改善 | 設定較複雜，需要網路已啟用 IPv6 |
我建議可先從 WARP 開始，這個比較像是 VPN 工具，只要打開，網路流量就會改走 Cloudflare 節點，自動繞過 HiNet 連往 Fastly 那段有問題的線路。只想長期改善 X 圖片與影片的人，可以再考慮改 hosts，我的實測中它對 X 的效果最好，不過稍有技術性，建議可研究一下再決定怎麼做。
另外，Cloudflare WARP 還可能會有一個問題，有部分服務會阻擋使用 WARP 連線的 IP 位址（例如 Dcard），開啟後若發現某些網站或服務無法正常進入，可以考慮使用第二種修改 hosts 的方法，它只會讓特定服務走 Cloudflare 節點，避免類似問題發生。
網站資訊
網站標題：1.1.1.1 with WARP（Cloudflare）
網站連結：https://one.one.one.one/zh-Hant/
方法一：用 Cloudflare WARP 繞開 Fastly 路線（推薦）
WARP 是 Cloudflare 提供的免費連線服務，會把你的流量先送到 Cloudflare 的網路，再轉往目的地，等於換了一條路走（很像是 VPN 的概念）。它無法修好 Fastly 本身的問題，但可以避開壅塞的那段路線，簡單來說，繞路走就不會塞在路上。
安裝與介面細節可以參考我之前寫的「Cloudflare WARP 桌面版」教學，這裡只整理針對這個問題的步驟。
先確認你的情況和上面描述的一致：X 文字正常，但是圖片影片轉圈跑不出來或是很慢。如果整個網站都打不開，或是白天也一樣慢，可能是其他問題，不一定適用本文方法。
開啟 Cloudflare 的 1.1.1.1 官網，依照你的裝置下載應用程式，支援 Windows、macOS、Linux、iOS 與 Android，使用者如果更習慣 Homebrew，也可以輸入下列指令安裝：
brew install --cask cloudflare-warp
開啟 WARP 應用程式後，把主開關切換到連線狀態。
Mac 第一次啟用時，系統會跳出「是否允許加入 VPN 設定」的提示，按「允許」。接著進入設定，確認模式為 WARP（預設模式，會加密並轉送全部流量）。若選到只有 DNS 的 1.1.1.1 模式，只會改 DNS，但是路由不會改變，對這個問題沒有幫助。
用瀏覽器開啟 https://cloudflare.com/cdn-cgi/trace，如果出現 warp=on，就代表流量已經透過 WARP 傳送。
重新整理 X 的頁面，看圖片與影片是否正常載入，或試著下載一個 GitHub 的檔案，速度會明顯不同。
以我的實測為例，X 圖片的載入時間從約 12 到 17 秒降到 0.32 秒（本來一直轉圈跑不出來），GitHub 的下載速度從約 40 KB/s 提升到約 27 MB/s，詳細數據在下方「我的實測結果」。
如果用完後不需要，可以把 WARP 關閉，避免所有流量都繞道，也能避免某些網站或服務無法正常打開的問題。
方法二：只想改善 X，可以修改 hosts
hosts 是系統內建的網域對照表，可以強制讓特定網址連到你指定的 IP，這個方法的核心概念是：讓 X 的圖片與影片網域改連 Cloudflare 的線路（所以原有的網域後面會加上 .cdn.cloudflare.net），避開壅塞的 Fastly 路線。
先查出設定值
X 的兩個網域可以透過 Cloudflare 提供的對應網址，查到目前的 IPv4 位址。Windows 在命令提示字元、Mac 在終端機輸入：
nslookup pbs.twimg.com.cdn.cloudflare.net
nslookup video.twimg.com.cdn.cloudflare.net
把結果中的 IPv4 位址，分別填進下面對應的位置，以我的實測為例，pbs.twimg.com 指向 Cloudflare 的 IP 之後，原本要 12 秒以上的圖片只要約 0.1 秒，連續 10 次都穩定載入（0.10 到 0.16 秒），回應碼為 200，HTTPS 憑證也驗證正常。另一個 video.twimg.com 的 1080p 影片分段檔也從約 4.75 秒降到約 0.17 秒（10 次中只有 1 次偏慢，約 0.63 秒）。
# 以下是我在 2026-10-08 實測有效的 IP，請用上面的 nslookup 查出你的最新值
104.18.37.127 pbs.twimg.com
104.18.36.146 video.twimg.com
Windows 設定
- 在開始選單搜尋「記事本」，按右鍵選擇「以系統管理員身分執行」。
- 選擇「檔案」→「開啟」，在路徑欄輸入
C:\Windows\System32\drivers\etc。 - 把右下角的檔案類型從「文字文件」改成「所有檔案」，選擇名為
hosts的檔案開啟。 - 在檔案最下方換行，貼上上面的設定，按 Ctrl + S 存檔。如果跳出「另存新檔」的視窗，代表第 1 步沒有以系統管理員身分執行。
- 在命令提示字元執行
ipconfig /flushdns，接著完全關閉瀏覽器再重新開啟。
Mac 設定
- 開啟「終端機」，輸入
sudo nano /etc/hosts，按 Enter 後輸入開機密碼。 - 用方向鍵移到最下面，貼上設定。
- 按 Ctrl + O 存檔，按 Enter 確認，再按 Ctrl + X 離開。
- 執行
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder清除 DNS 快取，再重新開啟瀏覽器。
Mac 如果常需要切換 hosts 設定，也可以改用 iHosts 這類 Hosts 編輯工具。
如何還原
把剛才新增的那幾行刪掉，存檔後重開瀏覽器，就會回到原本的狀態。
手機怎麼辦？
手機無法直接修改 hosts，如果你使用 NextDNS 這類可自訂 DNS 規則的服務，可以在其「重寫」功能加入改寫規則，把 X 的兩個網域指向對應的 .cdn.cloudflare.net 網址，這樣 Cloudflare 的 IP 變動時會自動跟著更新，而且不用碰系統檔案，隨時都可以從控制台去新增或是刪除重寫規則。
方法三：GitHub 進階，強制走 IPv6
HackMD 作者 TimLiu 的分析指出，問題集中在 HiNet 固網的 IPv4 路線，IPv6 則正常，但 GitHub 的下載相關網域（例如 release-assets.githubusercontent.com、objects.githubusercontent.com 等六個）都沒有公開 IPv6 紀錄，所以裝置只能使用有問題的 IPv4。作者的做法是透過 AdGuard、路由器的 DNS 設定，或是 hosts，替這些網域補上 IPv6 位址。
執行前要先確認自己的網路有 IPv6：用瀏覽器開啟 test-ipv6.com，分數需為 10/10，或在終端機執行 curl -6 -I https://github.com，能連上才代表有 IPv6，有需要詳細設定方式的讀者請參考 HackMD 原文。
這個方法的風險在於 GitHub 的 IPv6 位址之後可能變動，需要定期檢查，不熟悉網路設定的人建議直接用方法一。另外要說明，我用 curl -6 在自己的網路測試時，連線直接失敗，代表我的環境沒有可用的 IPv6，所以這個方法我無法實測。
我的實測結果
以下是我在 2026 年 10 月 7 日晚上 10 點 40 分到 11 點之間，用 curl 在中華電信光纖（300/300 Mbps）、Mac 上實測的結果。每個項目重複 5 次（GitHub 3 次）取中位數。「改善前」與 WARP 是 10 月 7 日晚上的量測；hosts 欄是 10 月 8 日晚上 10 點 07 分到 11 分，實際修改 hosts 後的結果（X 的圖片與影片各 10 次），並用 curl 的輸出確認連到的是指定的 IP。
| 項目 | 改善前 | WARP | hosts（指向 Cloudflare） |
|---|---|---|---|
| X 圖片（約 818 KB） | 12 到 17 秒 | 0.32 秒 | 0.11 秒 |
| X 影片（1080p 分段，約 2.15 MB） | 4.75 秒 | 0.39 秒 | 0.17 秒 |
| Twitch 網頁 | 1.35 秒 | 0.27 秒 | — |
| Twitch 縮圖 | 0.52 秒 | 0.24 秒 | — |
| GitHub 下載速度 | 約 40 KB/s，20 秒下載不完 | 約 27 MB/s，2.4 秒下載完約 64.5 MB | 約 43 KB/s，沒有改善（不適用） |
| YouTube 縮圖載入時間 | 0.09 秒 | 0.11 秒 | 不受影響 |
三點說明：Fastly 回給我的節點會變動，在另外兩輪基準測試中，X 影片與 Twitch 網頁曾連到 199.232.x.x 的節點而明顯較快（1080p 分段約 0.78 秒），所以影片與 Twitch 的改善幅度會依當下情況而異。
X 圖片的慢也不是每次都一樣：表中「改善前」取自前兩輪，每輪都約 16 秒；最後一輪（還原 hosts 之後）5 次中有 2 次仍要 12 到 17 秒，另外 3 次降到 0.6 到 0.7 秒，代表壅塞的程度時好時壞，但體感上會覺得很慢很卡。
相較之下，GitHub 三輪都只有 40 到 50 KB/s，結果最穩定。即使在 X 圖片比較順的狀態（0.6 到 0.7 秒），改 hosts 後的 0.11 秒仍然更快。
常見問題
換成 1.1.1.1 的 DNS 有用嗎？
沒有幫助，DNS 只負責查詢網址對應的 IP，無法改變連線走的路線。
WARP 要一直開著嗎？
不需要。建議在晚間尖峰、需要用到 X、Twitch 或 GitHub 時再開，用完可以關閉，以免在瀏覽某些網站時被阻擋或無法連線。
hosts 改完之後 X 圖片全白怎麼辦？
通常是設定的 IP 已經失效，先刪除新增的行還原，再用 nslookup 重新查一次最新的 IP。
這個問題什麼時候會好？
目前沒有看到官方的公開說明，無法確定。可以追蹤本文的更新。
不想錯過好用的免費資源嗎？
已有 3.5 萬位讀者訂閱，新文章直接寄到你的信箱。
