一個在 2026 年這麼先進的年代，正在真實發生的網路慘劇
最近看到不少人在網路上哀嚎，明明家裡辦的是幾百 M、1G，甚至 2G 的中華電信光世代，平常 Speedtest 跑起來也是滿速，但只要從 GitHub 下載東西，速度突然就剩下幾十 KB/s。
滑個 X（Twitter）也是很有趣，文字一下就出來，圖片在那邊轉圈圈，影片更像是在考驗人生耐性 🐢
第一個直覺通常都是：
我家網路壞了嗎？
結果 Speedtest 一跑：
900 Mbps。
GitHub 再下載一次：
23 KB/s。
？？？？？ 🤡
但其實網路上稍微爬一下，就會發現這根本也不是最近才突然冒出來的問題。
早在之前就一直有人回報 HiNet 連往部分 GitHub、Fastly CDN 資源時，會發生異常緩慢的狀況。
例如 2025 年就有人實測 objects.githubusercontent.com 在尖峰時間只剩下約 1 Mbps 左右。
相關討論：
巴哈姆特：最近 HiNet 光纖固網連 Fastly CDN 速度是不是很慢啊
而這次從大量使用者回報與實際測試的現象來看，問題同樣高度集中在：
HiNet → Fastly CDN
這一段網路路徑。
截至本文撰寫時，GitHub 的 objects.githubusercontent.com 解析到的網路屬於 Fastly AS54113，而 X 的部分圖片資源，例如 pbs.twimg.com，同樣也會經過 Fastly。
這就可以解釋一個很奇妙的現象：
你的網路其實沒有「整條壞掉」。
Google 很快。
YouTube 很快。
Speedtest 滿速。
甚至 GitHub 網頁本身打開也很正常。
但是一按 Releases 開始下載檔案：
瞬間夢迴 1999 年。
今年都已經 2026 快 2027 了，家裡牆壁接的是光纖，實際下載速度卻讓人懷疑數據機等等會不會突然開始：
嘰～～～嘎～～～滋滋滋～～～☎️
發出撥接網路的聲音 😂
Fastly 在台灣好像真的有點不一樣
更有趣的是，開放文化基金會在 2026 年發布的「台灣國際網路中斷風險」研究中，也觀察到 Fastly 與 Google、Cloudflare 有非常明顯的差異。
在該研究針對台灣常用網站所觀測到的國際公有雲資源請求中：
| CDN / 雲端業者 | 境內節點請求 | 境外節點請求 |
|---|---|---|
| 7,393 | 63 | |
| Cloudflare | 3,051 | 21 |
| Amazon | 1,382 | 522 |
| Akamai | 446 | 13 |
| Fastly | 6 | 369 |
| Microsoft | 196 | 143 |
Fastly 在這份研究樣本中，有 369 筆請求被判定連往境外節點，只有 6 筆是境內節點。
也就是說，在這批研究樣本裡面，Fastly 的請求有非常高的比例落在境外節點。
相較之下：
Google 是 7,393 筆境內、63 筆境外。
Cloudflare 則是 3,051 筆境內、21 筆境外。
先特別強調一下：
這裡的 6 與 369 指的是研究觀測到的「請求數」，不是 Fastly 在台灣只有 6 台 Server，也不是只有 6 個 PoP。
不過至少從這份研究的觀測結果來看，Fastly 資源對境外連線的依賴程度，確實明顯高於 Google 與 Cloudflare。
因此當國際網路路由出現壅塞或異常時，這類需要跨境取得的 CDN 資源，理論上自然也更容易受到影響。
所以到底是哪裡塞住？
這邊先講一個很常見的誤解。
ISP 的網路並不是：
A 線塞車 → 按一下按鈕 → 全部改走 B 線
這麼簡單 😆
真正的 Internet Routing 會牽涉到很多東西：
BGP、Public Peering、Private Peering、Transit、CDN 節點選擇、互連頻寬、路由政策，以及 ISP 與 CDN 之間的商業合作關係。
所以就算「理論上還有別條路」，也不代表 ISP 可以像 Google Maps 一樣：
國一塞車了？
好，幫全台灣幾百萬用戶全部改走國三。
實際的網際網路沒有這麼單純。
但對一般使用者而言，最後看到的結果還是一樣：
有一條路塞爆了，但自己的流量還是在走那條路。
就像今天從台北開車去高雄。
國道一號前面發生事故，已經塞成大型停車場。
你打電話問客服：
前面是不是塞車？
客服叫你先在台北市區繞一圈測速。
然後跟你說：
您目前時速 80 公里正常喔，這邊看起來沒有問題 😊
問題是……
我要去高雄啊幹！🔥
這大概就是這類問題最讓人抓狂的地方。
Speedtest 滿速，不代表你的 Internet 是滿速
因為 Speedtest 通常會自動選擇距離近、網路品質良好的測速節點。
所以測出：
900 Mbps
實際上只能證明：
你家 → 那台 Speedtest Server 很快。
完全不能證明：
你家 → Fastly 很快。
更不能證明：
你家 → GitHub、X 或某個海外網站也一樣快。
Internet 並不是一條從你家直接通到全世界的水管。
你去 Google、GitHub、Netflix、X、Apple，背後都有可能經過完全不同的 ISP、CDN、Peering 與國際線路。
所以遇到這種：
只有某幾個網站特別慢
的情況，一直重跑 Speedtest 其實意義非常有限。
HiNet 明明有這麼大的頻寬，為什麼不換一條路？
這時候可能有人會問：
中華電信明明有這麼龐大的國際頻寬，為什麼不把 Fastly 這條路拓寬一點？
事情其實也沒有這麼簡單。
網際網路不是中華電信自己蓋一條水管，想開多大就開多大。
ISP 與 Fastly 這類 CDN 之間，還牽涉到：
BGP、Transit、Public / Private Peering、互連位置、頻寬容量，以及雙方的商業合作關係。
甚至中華電信自己的 TWIX 公開費率裡面，就直接把：
HiNet 雙方互連（Private Peering）
列成一項按照 Mbps 計價的批發服務。
2026 年 4 月 1 日起的公開牌價是：
NT$23 / Mbps
而 Public Peering、Private Peering 以及符合特定條件後的免費互連，又是不同的機制。
當然，這並不代表 Fastly 現在就是按照這張 TWIX 公開價目表付錢給 HiNet。
大型 CDN 與電信商完全可能另外簽訂不同的互連協議。
這裡只是想說明一件事情：
Internet Peering 不只是純技術問題，本來就同時包含頻寬、設備與商業條件。
Fastly 自己公布的 Peering Policy 也是：
Selective Peering
也就是會根據 Performance、Capability，以及實際流量需要來決定 Peering 關係。
所以我們沒有足夠證據可以直接說：
「中華電信明明藏著一條完全沒人在用的高速線路，只是故意不開放給一般 HiNet 使用者。」
這種說法太武斷了。
但從使用者角度來看，最靠北的地方還是在這裡：
我每個月付的是幾百 Mbps、1 Gbps，甚至 2 Gbps 的網路費。
結果只因為 ISP 與某個 CDN 之間的一段互連品質不好，GitHub 就可以直接掉到幾十 KB/s。
而且更荒謬的是：
同一台電腦。
同一條光纖。
同一個 GitHub 檔案。
只有網路路徑不同：
HiNet → Fastly
幾十 KB/s 🐌
換成：
HiNet → Cloudflare WARP → Fastly
瞬間恢復正常 🚀
家裡的光纖沒有換。
電腦沒有換。
GitHub Server 也沒有換。
唯一改變的只是「封包走哪條路」。
這至少很強烈地指向一件事情：
問題並不是你家最後一哩光纖「頻寬不夠」，而更可能發生在通往目的 CDN 的其中某段網路路徑或互連。
至於這段壅塞到底是：
頻寬不足？
Peering 容量不足？
Transit 路徑品質不佳？
BGP Traffic Engineering？
還是雙方互連策略所造成的結果？
除非 HiNet 或 Fastly 公開相關網路與 Peering 數據，否則外部使用者其實沒有辦法只靠下載速度或一份 traceroute，就百分之百斷言真正原因。
我們唯一可以實際觀察到的是：
換一條路以後，速度就正常了。
求人不如求己
如果真的碰上這種 ISP 與特定 CDN / 海外路徑的問題，最簡單的測試方法其實就是：
開 VPN。
甚至不需要花錢。
直接下載免費的 Cloudflare WARP，打開之後重新下載一次 GitHub。
很可能會看到一個非常荒謬的畫面。
原本：
GitHub
32 KB/s 🐌
WARP 打開：
GitHub
30 MB/s 🚀
就這麼簡單。
一秒鐘從 1999 年回到 2026 年現代文明。
當然，上面的速度只是舉例，不代表每個人的實際速度都會一樣。
WARP 也沒有什麼神秘的「網路加速魔法」。
真正發生的事情其實只是：
你的網路路徑改變了。
原本可能是：
你
↓
HiNet
↓
某段壅塞的互連 / Transit / 國際路徑
↓
Fastly
↓
GitHub
打開 WARP 以後變成：
你
↓
HiNet
↓
Cloudflare
↓
Cloudflare 的全球網路與另一套路由 / Peering
↓
Fastly
↓
GitHub
原本有問題的那段路，被另外一條路繞過去了。
所以速度就可能瞬間恢復。
這也是為什麼 VPN 或 WARP，對這種：
「我的網路都正常，只有特定網站特別慢」
的問題特別適合拿來測試。
當然，WARP 並不是保證一定會變快。
如果替代路徑本身也塞車、距離更遠，甚至某個 VPN Server 自己就很慢，一樣完全可能越開越慢 🤡
但是如果你遇到的是：
DIRECT
40 KB/s
然後：
WARP
30 MB/s
那麼至少已經可以很大程度排除 Wi-Fi、網路線、SSD 或電腦本身是主要瓶頸。
問題高度指向：
中間的網路路徑。
換 1.1.1.1 DNS 沒有用
順便講一個非常常見的誤區。
Cloudflare 有：
1.1.1.1 DNS
以及：
Cloudflare WARP
這兩個東西。
它們不是同一件事情。
如果你只是把 DNS 改成：
1.1.1.1
那只是把：
「github.com 的 IP 是什麼？」
這個 DNS 查詢交給 Cloudflare。
真正開始下載 GitHub 檔案以後，你的封包基本上還是走原本 ISP 的 Internet Route。
所以：
換 DNS ≠ 換網路路由。
想測試這種 Fastly / GitHub 路徑問題，要真的把：
WARP Tunnel
打開。
不是單純把 DNS Server 改成 1.1.1.1。
Cloudflare 官方現在也把兩種模式明確區分開：
DNS only
只處理 DNS。
而：
Traffic and DNS / WARP
才會真的把裝置的 Internet Traffic 送進 Cloudflare 網路。
講這麼多，那你有聽過「科學上網」嗎？ 😁
直接把 WARP 打開的確很方便。
但是這又會遇到另外一個問題：
所有流量一起走 WARP。
也就是正常 WARP 模式打開以後，你電腦的大部分 Internet Traffic 都會先送進 Cloudflare 網路，再從 Cloudflare 出去。
GitHub 需要繞路。
合理。
X 需要繞路。
也合理。
但是：
我開個台灣網站。
查個銀行。
逛個購物網站。
明明原本 DIRECT 就超快。
到底為什麼也要陪 GitHub 一起繞 Cloudflare 一圈？ 😂
而且有些網站會針對 VPN、Data Center IP，甚至 Cloudflare WARP 的出口 IP 做額外風控。（例如：DCard）
所以最漂亮的方式其實不是：
全部走 WARP
而是：
GitHub → WARP
X / Twitter → WARP
其他網站 → DIRECT
也就是：
分流。
中國網友很喜歡把這整套東西稱為：
「科學上網」 😆
當然我們在台灣沒有 Great Firewall 要翻，這篇也不是在教大家翻牆。
只是背後的技術概念其實一模一樣：
根據 Domain、IP、Process 等規則，決定每一條連線到底要走 DIRECT 還是 Proxy。
2026 年其實已經不用自己生 WARP WireGuard 了
以前網路上很常看到一種做法。
先利用第三方工具取得 Cloudflare WARP 的 WireGuard 設定，例如：
https://lanrat.github.io/wireguard-warp-generator/
接著把 WireGuard Configuration 塞進 Clash、sing-box、Surge 等工具裡面。
這方法以前確實非常方便。
我原本也準備這樣寫這篇文章。
結果寫到一半仔細查了一下 2026 年的現況……
時代又變了。
Cloudflare WARP 現在主要使用：
MASQUE
作為預設 Tunnel Protocol。
一般 WARP 模式仍然可以使用 WireGuard，但 Cloudflare 目前的 Local Proxy Mode 已經使用 MASQUE。
更重要的是：
Cloudflare 官方現在直接提供了一個超級適合我們需求的功能：
Local Proxy Mode
它可以讓 WARP 在你的電腦本機開一個：
HTTPS / SOCKS Proxy
只有你指定送進這個 Proxy 的流量才會經過 WARP。
其他流量全部照舊。
而且這是 Cloudflare 官方功能，不需要使用任何第三方 WARP API 或 Generator。
既然官方自己都給 Proxy 了，我們根本不用再繞一大圈：
WARP
↓
第三方 Generator
↓
產生 WireGuard
↓
匯入 Clash
現在直接：
Clash
↓
WARP Local Proxy
結束。
少一層第三方工具。
少一份 Private Key。
也比較不用擔心哪天 Cloudflare API 一改：
全世界的 WARP Generator 一起暴斃 ☠️
所以以下就使用目前我覺得最乾淨的方法。
Cloudflare WARP + Clash Verge Rev
這篇以桌面電腦為例。
因為 Cloudflare WARP 的 Local Proxy Mode 目前只提供 Desktop Client 使用。
首先下載兩套免費軟體。
Cloudflare WARP：
Clash Verge Rev：
https://github.com/clash-verge-rev/clash-verge-rev
Clash Verge Rev 是一套目前仍持續積極維護的 Mihomo GUI Client。
支援：
Windows、macOS、Linux。
安裝 Cloudflare WARP 後，進入：
Preferences
→ Advanced
→ Configure Proxy
打開 Local Proxy。
Port 可以自己選。
例如：
40000
設定完成之後，再把 WARP Mode 切換成：
Local Proxy
這時候 Cloudflare WARP 就不會再把整台電腦的所有 Internet Traffic 全部接管。
只有主動送到：
127.0.0.1:40000
的流量才會走 WARP。
其他網路全部照舊。
這就是我們想要的東西 😎
把 WARP 塞進 Clash / Mihomo
接下來只需要把剛才建立的 WARP Local Proxy，當成一個普通的 SOCKS5 Proxy 交給 Mihomo。
概念大概如下：
proxies:
- name: WARP
type: socks5
server: 127.0.0.1
port: 40000
這樣 Clash / Mihomo 裡面就多出一個叫：
WARP
的 Proxy。
它不是什麼付費機場。
也沒有跑到不知道哪一國的 VPS。
它單純就是：
你自己電腦本機上的 Cloudflare WARP。
接下來才是重點：只把 GitHub、X 丟進去
自己一條一條寫 Domain 當然可以。
例如：
rules:
- DOMAIN-SUFFIX,github.com,WARP
- DOMAIN-SUFFIX,githubusercontent.com,WARP
- DOMAIN-SUFFIX,githubassets.com,WARP
- DOMAIN-SUFFIX,x.com,WARP
- DOMAIN-SUFFIX,twitter.com,WARP
- DOMAIN-SUFFIX,twimg.com,WARP
- MATCH,DIRECT
最下面這條：
- MATCH,DIRECT
非常重要。
意思就是：
前面的規則全部都沒有命中，就直接連線。
所以最後效果會變成：
GitHub
電腦 → Clash → WARP → GitHub
X
電腦 → Clash → WARP → X
但是：
Dcard
電腦 → Clash → DIRECT → Dcard
Google
電腦 → Clash → DIRECT → Google
銀行
電腦 → Clash → DIRECT → 銀行
這才是我真正想要的效果。
該繞路的才繞。
不該繞的不要跟著出去環島。 😆
懶得自己整理 Domain？當然有人幫你整理好了
網路上其實已經有很多人長期維護各種服務的 Domain / IP Ruleset。
例如：
blackmatrix7 / ios_rule_script
裡面已經整理了非常多常見平台。
GitHub：
Twitter / X：
https://github.com/blackmatrix7/ios_rule_script/tree/master/rule/Clash/Twitter
另外還包括：
Apple、Telegram、YouTube、Netflix、Disney+、OpenAI、Google、Microsoft……
一般常見的平台基本上都能找到。
而且這類規則會隨著服務使用的 Domain 調整而持續更新，所以比自己硬寫幾十條 Domain 好維護很多。
Mihomo 本身也支援：
rule-providers
所以根本不用把整份 Ruleset Copy Paste 進自己的 Config。
例如：
rule-providers:
GitHub:
type: http
behavior: classical
format: yaml
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/GitHub/GitHub.yaml"
path: ./ruleset/GitHub.yaml
interval: 86400
Twitter:
type: http
behavior: classical
format: yaml
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Twitter/Twitter.yaml"
path: ./ruleset/Twitter.yaml
interval: 86400
rules:
- RULE-SET,GitHub,WARP
- RULE-SET,Twitter,WARP
- MATCH,DIRECT
其中：
interval: 86400
代表每 86400 秒，也就是每天更新一次 Ruleset。
未來 GitHub 多一個 Domain。
不用自己回來改設定。
交給規則庫更新就好了 😁
最後就變成真正的「哪裡壞掉就繞哪裡」
設定完成之後，Clash Verge Rev 可以常駐開著。
但這跟以前：
VPN 一開，全家一起出國
的概念已經完全不同。
正常情況：
大部分網站 → DIRECT
真的有問題的平台：
GitHub → WARP
X → WARP
假設今天：
GitHub Fastly 塞車？
GitHub → WARP
明天 X 圖片開始轉圈？
Twitter → WARP
哪天 HiNet → Fastly 又恢復正常？
直接讓 GitHub 回：
DIRECT
甚至如果你自己還有：
其他 Proxy、VPS、WireGuard、家裡的 VPN、Surge Ponte……
也全部可以塞進同一套 Rules 裡面。
不同平台走不同網路。
哪一條路適合，就走哪一條。
這其實才是 Proxy Rule 真正好玩的地方。
那前面的 WARP WireGuard Generator 還能不能用？
可以。
Clash Verge Rev 底層的 Mihomo 目前仍然支援 WireGuard Proxy。
所以如果你真的不想安裝官方 Cloudflare WARP Client，還是可以透過第三方工具取得 WARP WireGuard Parameters，再自己建立 WireGuard Node。
只是到了 2026 年，我已經不太推薦一般使用者把這種方式當成第一選擇。
原因很簡單：
Cloudflare 並沒有承諾這些第三方 WARP Generator 使用的 API 或流程會永遠保持不變。
哪天 Registration API 改掉。
Endpoint 改掉。
驗證方式改掉。
第三方工具都可能跟著失效。
相比之下：
Local Proxy 是 Cloudflare 官方正式提供的功能。
能少一層魔改，我通常就少一層 😆
sing-box 使用者要注意舊教學
另外如果你是 sing-box 使用者，也要特別注意一件事情。
網路上很多舊教學使用的是：
{
"type": "wireguard"
}
這種舊版的：
WireGuard Outbound
但它從 sing-box 1.11.0 就已經進入 Deprecated。
到了：
sing-box 1.13.0
更正式移除了舊 WireGuard Outbound。
現在應該使用新的：
WireGuard Endpoint
架構。
所以 2026 年再看到兩三年前的 sing-box + WARP 教學：
千萬不要整份無腦 Copy 下去。
不然很可能一貼進去直接：
unknown outbound type: wireguard
☠️
怎麼確定自己的 WARP Proxy 真的有動？
最簡單可以直接用 curl 測試。
假設前面 WARP Local Proxy Port 設定成：
40000
執行：
curl --proxy socks5h://127.0.0.1:40000 https://www.cloudflare.com/cdn-cgi/trace
正常情況下，可以在輸出裡面找到：
warp=on
代表這次 curl 的流量確實有進入 Cloudflare WARP。
接著再實際測試 GitHub Release。
找一個原本下載速度異常的大檔案。
先 DIRECT 下載。
再透過 WARP 下載。
假設看到類似：
DIRECT
43 KB/s
然後：
WARP
28 MB/s
那麼基本上已經可以很明顯看出：
你家幾百 Mbps 的光纖本身並沒有只能跑 43 KB/s。
真正造成差異的：
是中間走的路不一樣。 🤣
最後
其實整件事情最荒謬的地方，並不是 GitHub 偶爾很慢。
網際網路本來就是一個由無數：
ISP、CDN、Transit、IX、Peering、BGP……
拼起來的巨大怪物。
其中任何一段發生 Congestion、Routing 異常或互連品質下降，都可能讓某幾個特定服務突然變慢。
真正讓一般使用者很無奈的是：
你看到的永遠只有：
Speedtest 正常。
機房正常。
數據機正常。
網路線正常。
光纖訊號正常。
你的方案正常。
然後 GitHub：
18 KB/s。
💩
最後解決問題的方法竟然只是：
讓封包換一條路走。
2026 年都快過完了。
家裡可能已經是：
Wi-Fi 7。
2.5G / 10G LAN。
1G / 2G FTTH。
最新的 Mac、PC。
結果下載一個 GitHub Release，最後還得自己開始研究：
BGP。
CDN。
VPN。
WARP。
SOCKS5。
Mihomo。
Ruleset。
Peering。
Traffic Engineering……
才能把原本理論上應該跑幾百 Mbps 的 Internet 救回來。
只能說：
科技始終來自於人性。
而網路工程始終來自於：
幹，怎麼又塞了。 🔥
至少下一次 GitHub 又只剩下 20 KB/s 的時候：
不用再一直重開數據機。
不用換網路線。
也不用對著 Speedtest 的 900 Mbps 懷疑人生。
打開 Clash。
讓 GitHub 走 WARP。
然後繼續假裝自己活在 2026 年的現代社會吧 🖖