如何改善網路品質 - X/推特影片

Posted on 2026-02-08

你是否遇過這種情況：家中的中華電信 300M/500M 甚至 1G 光纖，測速時數據非常漂亮，但打開手機 Twitter (X) 看影片時卻一直轉圈圈，反而切換到行動網路 5G 就瞬間流暢？

這次我試圖針對 RouterOS (MikroTik) 進行了一次優化。這不僅僅是「改改設定」，更是一次從 解析 (L7)、傳輸 (L4) 到安全性協定 三個面向的「網路底層重構」。以下是核心邏輯與設定摘要。

此次結果為個人嘗試結果，實測有可見的改善，也可能因為各種外在因素而無法改善你的情況，請見諒。

以下設定皆為 RouterOS 為出發的設定，請自行對應至自家的 Router 設定。

DNS 與 CDN 定位優化：解決「繞路」問題 (L7 解析層)

【現狀與問題】

許多人習慣直接使用 ISP 自動配發的 DNS。然而，Twitter 等大型平台依賴 CDN (內容遞送網路) 來提供影片流。如果 DNS 解析不夠精確，CDN 可能會誤判你的位置，將你導向日本、新加坡甚至美國的伺服器，導致 RTT (往返時延) 大增。

【優化動作】

固定上游 DNS： 使用 168.95.1.1 (HiNet) 確保在地化解析優先，搭配 1.1.1.1 (Cloudflare) 提升解析速度。
關閉 use-peer-dns： 避免 PPPoE 介面強行覆蓋你的自訂設定。

【RouterOS 指令】

# 設定上游 DNS 並允許區網查詢，可自行替換成你喜歡的 DNS  
/ip dns set allow-remote-requests=yes servers=168.95.1.1,1.1.1.1

# 停用 PPPoE 自動取得 DNS (請將 pppoe-out1 改為你的介面名稱)  
/interface pppoe-client set [find name="pppoe-out1"] use-peer-dns=no

MSS Clamping 封包優化：解決「被丟棄的封包」 (L4 傳輸層)

【現狀與問題】

中華電信的 PPPoE 環境中，MTU 通常是 1492。如果 TCP 握手時協商的 MSS 過大，會導致超過 MTU 的大封包在傳輸過程中被丟棄（Silent Drop），進而引發大量重傳，體感上就是影片載入卡死。

【優化動作】

精確 Mangle 規則： 手動新增 Mangle 規則強制 new-mss=1452 (1492 - 40 bytes TCP/IP header)。

在某些環境下，如果 MSS 設為 1452 依然有問題，為保險起見設為 1440 或 1410（考慮到可能有其他封裝如 IPv6 或 VPN）。

【RouterOS 指令】

# 移除舊有的 clamp-to-pmtu 設定 (如果有的話)  
/ip firewall mangle remove [find comment="change mss"]

# 新增精確的 MSS 修改規則  
/ip firewall mangle add action=change-mss chain=forward comment="Fix Twitter/Netflix MSS"   
    new-mss=1452 out-interface=pppoe-out1 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1453-65535

3. 解放 QUIC 協定：擁抱現代化的快傳模式 (防火牆層)

【現狀與問題】

Twitter 大量使用基於 UDP 的 QUIC (HTTP/3) 協定。許多舊式規則會阻擋 UDP 443，或是因為 ICMP 被阻擋導致 Path MTU Discovery (PMTUD) 失效。

【優化動作】

放行 UDP 443 (QUIC)： 確保基於 UDP 的 QUIC 流量不會被防火牆誤攔或因 FastTrack 導致處理異常。
啟用 ICMP： 讓 Path MTU 發現機制能正常運作。

【RouterOS 指令】

# 在 FastTrack 之前放行 QUIC (UDP 443)  
/ip firewall filter add action=accept chain=forward comment="Allow QUIC (Twitter Speedup)"   
    dst-port=443 protocol=udp place-before=[find action=fasttrack-connection]

# 放行 ICMP (確保 PMTUD 運作)  
/ip firewall filter add action=accept chain=input protocol=icmp  
/ip firewall filter add action=accept chain=forward protocol=icmp

4. 物理參數鎖定：消除協商誤差 (Interface)

【現狀與問題】

RouterOS 在與 ISP 機房對接時，若 MTU/MRU 設為 auto，有時會產生微小的協商誤差。

【優化動作】

將 pppoe-client 的 max-mtu 與 max-mru 手動固定為 1492。

【RouterOS 指令】

1 2	# 強制鎖定 PPPoE 物理參數 /interface pppoe-client set [find name="pppoe-out1"] max-mru=1492 max-mtu=1492

DNS Static：指定網域解析至特定 IP (進階優化)

【現狀與問題】
網路上也有一篇教學是手動指定網域對應的 IP:

例如：Hiraku 大大的這篇「Twitter 圖片打不開的解決方案」
https://hiraku.dev/2020/07/6272/

這原理是即便 DNS 設定正確，有時 CDN 節點仍會因負載平衡將你分配到不穩定的 IP。透過手動指定網域對應的 IP（DNS Static），可以強迫設備存取你測試後最快的節點。
你可以按照下面的方法直接在 Router 改好，就不用家中每個設備都設定一次。

【優化動作】

在 RouterOS 中手動新增 A 紀錄。例如將 Twitter 圖片伺服器 pbs.twimg.com 固定指向特定的高速節點。

【RouterOS 指令】

1 2	# 將指定網域解析至特定 IP (以 pbs.twimg.com 為例) /ip dns static add name=pbs.twimg.com address=146.75.112.159 ttl=1d

由於 CDN 的 IP 可能會隨時變動或因負載平衡調整，手動寫死 DNS Static 雖然短期見效，但長期可能會因為節點失效導致圖片完全跑不出來。建議定期檢查或使用 nslookup 重新確認。

路由出海優化：固定制 IP 與 Google 骨幹快線

【核心概念】
家用寬頻在尖峰時段的出海優先權通常較低。要解決這個物理層面的瓶頸，有兩個主要的進階方案：

方案 A：使用中華電信非固定制的固定 IP

中華電信提供非固定制用戶申請一個「固定 IP」（格式為 [email protected]）。這類 IP 通常在機房端擁有較乾淨的路由，也許可以改善跨海連線的穩定度。

方案 B：申請中華電信固定制IP

中華電信其實還提供企業上網的需求，這類 IP 的封包在出海時擁有比較高的優先權，原則上可以比方案 A 更好。

有興趣可以參考：「光世代固定制」
https://www.cht.com.tw/home/campaign/Hinet/fttx.html

方案 C：利用 GCP 台灣節點與 Google 頂尖骨幹網路 (Premium Tier)

Google 擁有全球最大的私有網路基礎設施之一。在 GCP 台灣機房架設 VPN，並選擇 Premium Tier 網路服務，你的封包將會儘可能地在 Google 的私有骨幹網路中傳輸，避開公網的擁塞。

相關介紹：「Google Cloud 網路基礎架構介紹：Premium Tier vs Standard Tier」
https://vocus.cc/article/65fedf8efd8978000166be76

總結

這次改動的邏輯可以總結為：「定位要準 (DNS)、分段要對 (MSS)、路徑要通 (QUIC)、封包優先權要高」。

當我們把這些底層瓶頸打通後，即便寬頻速率沒變，影片串流的體感卻會有明顯的改善。透過上述的 RouterOS 指令，至少我們可以確保網路封包以最高效、最穩定的方式傳輸。

DNS 與 CDN 定位優化：解決「繞路」問題 (L7 解析層)

MSS Clamping 封包優化：解決「被丟棄的封包」 (L4 傳輸層)

3. 解放 QUIC 協定：擁抱現代化的快傳模式 (防火牆層)

4. 物理參數鎖定：消除協商誤差 (Interface)

DNS Static：指定網域解析至特定 IP (進階優化)

路由出海優化：固定制 IP 與 Google 骨幹快線

方案 A：使用中華電信非固定制的固定 IP

方案 B：申請中華電信固定制IP

方案 C：利用 GCP 台灣節點與 Google 頂尖骨幹網路 (Premium Tier)

總結

也許你也會想看看