遊戲路由器的 QoS 設定：為什麼「遊戲加速」有時反而變慢
標記（Marking）：幫封包貼上 DSCP（Differentiated Services Code Point）標籤，告訴下游設備「這個很重要」。麻煩的是，很多家用路由器只在自己內部標記，一出門到 ISP 就被洗掉，所以標記的實際效果取決於整條路徑的配合程度。
排隊（Queuing / Scheduling）：這是最關鍵的一步。路由器會把封包放進不同佇列，然後用特定演算法決定送出順序。常見的有 FIFO（先來先送，等於沒排隊）、優先權佇列（Priority Queuing，高優先權插隊）、加權公平佇列（WFQ）等。排隊策略設計不良，就是「遊戲加速反而變慢」的頭號戰犯。
二、路由器上的「遊戲加速」到底在做什麼？
廠商在包裝盒上印的「Gaming Boost」、「Game Accelerator」、「電競模式」，其實是行銷詞彙，不是技術標準。同一個名字在不同品牌、不同型號上，可能代表完全不同的東西。以下拆解市面上常見的四種實作方式。
廠商宣傳的功能 vs 實際運作的機制
你在廣告上看到的通常是「一鍵加速、降低延遲 50%」。但實際在路由器後台運作的，多半是以下四種機制的組合，而且每一種都有它的副作用。
第一種：裝置優先權（Device Prioritization）。這是最常見也最陽春的做法。你把遊戲主機或電競 PC 設為「最高優先」，路由器就會把它的封包排到最前面。聽起來很合理，但如果家裡同時有人在看 4K Netflix，而你的頻寬本來就不夠，優先權只是讓遊戲封包「先排隊」，不代表它們「跑得快」。如果總頻寬已經被吃滿，優先權只能保證遊戲封包不被延後，但無法變出更多頻寬。
第二種：應用程式優先權（Application Prioritization）。路由器內建一份應用程式清單，你勾選「遊戲」類別，它就會嘗試辨識遊戲流量並給予優先權。問題在於，這份清單往往更新緩慢，新遊戲可能被歸類到「其他」；更糟的是，某些遊戲使用隨機埠或加密流量，DPI 根本認不出來，結果你以為開了加速，實際上遊戲封包還是走在一般佇列裡。
第三種：頻寬保留（Bandwidth Reservation）。路由器會保留一段頻寬專門給遊戲使用，例如「保留 20% 下行給遊戲裝置」。這招在頻寬充足時很有效，但在頻寬吃緊時會造成反效果——那 20% 被保留的頻寬在遊戲沒用滿時，其他應用程式也不能用，整體吞吐量反而下降，而遊戲本身也不會因為「保留」而變快。
第四種：流量整形（Traffic Shaping）加上智慧佇列。這是相對正確的做法，路由器會主動限制總頻寬在線路容量的 90% 到 95%，避免封包在 ISP 端排隊，然後用 fq_codel 或 CAKE 這類演算法管理佇列。這種做法對降低緩衝膨脹（Bufferbloat）很有效，但需要路由器有足夠的 CPU 效能，而且設定參數必須正確。
遊戲加速常見的四種實作方式
把上面四種機制對應到實際選單，你會看到這些選項：
三、為什麼開了遊戲加速反而變慢？六大元凶
接下來是本文的核心。以下六個原因，幾乎涵蓋了九成「開了加速卻更卡」的案例。你可以一邊讀，一邊對照自己路由器的設定。
（一）頻寬估算錯誤，把水管當成高速公路
這是頻率最高的錯誤。很多路由器的 QoS 設定頁面會問你「你的網路頻寬是多少」，然後使用者就照著電信方案填「500M/250M」。問題是，你填的數字必須是「實際可用的穩定頻寬」，而不是「理論最大值」。
舉個例子：你申辦 500Mbps 下行，但晚上八點尖峰時段，ISP 到你家的實際吞吐量可能只有 420Mbps。如果你在路由器裡填 500Mbps，QoS 的流量整形就會以為自己還有 80Mbps 的餘裕，於是讓更多封包進入佇列，結果這些封包全部堆在 ISP 端的緩衝區裡排隊，延遲從 15ms 暴增到 150ms。這就是典型的 Bufferbloat（緩衝膨脹）。
正確做法是：用實測值打八到九折。測速時要用有線連接、關掉其他裝置、在尖峰時段多測幾次，取最小值，然後再乘以 0.85 到 0.9。例如實測穩定 420Mbps，QoS 就填 360Mbps 到 380Mbps。這樣做的目的是「讓路由器成為瓶頸」，而不是讓 ISP 的緩衝區成為瓶頸。聽起來違反直覺，但這是控制延遲的關鍵。
（二）優先權泛濫，人人都是 VIP 等於沒有 VIP
第二個常見錯誤，是把太多東西設為「最高優先」。很多玩家會把遊戲、Discord、瀏覽器、甚至 Spotify 都設為高優先，想說「這些都是我打遊戲時會用的」。結果路由器一看，佇列裡八成封包都是高優先，優先權機制等於失效，大家還是一起排隊。
QoS 的優先權設計有一個鐵律：高優先權的流量佔比不應該超過總頻寬的 30% 到 40%。遊戲封包本身很小，一支遊戲的流量通常只有 50kbps 到 300kbps，佔比極低。真正該被壓制的是背景下載、雲端備份、Windows Update 這種會瞬間吃滿頻寬的流量。
正確的優先權配置應該是金字塔型：最頂端只放「遊戲主機或電競 PC 的遊戲埠」；第二層放「語音通訊」；第三層放「一般瀏覽與串流」；最底層放「下載、P2P、備份」。與其把遊戲拉高，不如把下載壓低，效果往往更明顯。
（三）上行頻寬被吃光，下行再快也沒用
這是最被忽略的一點。多數人的網路方案是「下行 500M、上行 50M」這種不對稱頻寬。遊戲本身的上行流量很小，但遊戲的「即時性」極度依賴上行——你的操作指令必須在幾十毫秒內送到伺服器。
問題來了：當家裡有人用 Google Drive 備份照片、用 iCloud 同步、或是開著 BT 下載，這些應用的上行 ACK 封包會瞬間塞滿那條只有 50M 的上行通道。你的遊戲操作指令只能排在這些 ACK 後面，ping 就從 20ms 跳到 200ms。很多人只設定下行 QoS，卻忘了上行才是遊戲延遲的真正命門。
解法很簡單但很少人做：上行頻寬的 QoS 限制要比下行更嚴格。實測上行 48Mbps，就填 40Mbps；並且把「上傳備份」、「雲端同步」、「P2P」這類應用直接丟到最低優先權，甚至設定上傳速率上限。與其花錢升級到 1G 方案，不如先把上行管好，延遲改善會更有感。
（四）硬體效能不足，QoS 本身就是負擔
QoS 不是免費的。每一個封包都要經過分類、標記、排隊，這些都是 CPU 工作。入門級路由器的 CPU 時脈可能只有 800MHz，當你開啟「智慧 QoS」加上「DPI 深度封包檢測」加上「家長監護」加上「防毒」，封包處理速度可能跟不上線路速度，反而造成額外延遲。
這種情況的典型症狀是：關掉 QoS 時 ping 是 20ms，打開後變成 35ms 到 50ms，而且不論網路有沒有壅塞都一樣。這代表 QoS 的處理成本已經超過它帶來的好處。
判斷方法很簡單：在路由器後台看 CPU 使用率，如果開啟 QoS 後 CPU 長期超過 70%，或是開啟後整體吞吐量明顯下降（例如從 500M 掉到 300M），那就是硬體撐不住。這時候的解法不是調參數，而是關掉 DPI 類的智慧功能，只留最基本的流量整形；如果連這樣都撐不住，就該換一台有硬體 NAT 加速、CPU 較強的路由器。
（五）深度封包檢測 DPI 誤判遊戲流量
很多「遊戲加速」功能背後是靠 DPI 辨識流量。DPI 會檢查封包內容的特徵碼，判斷這是哪一款遊戲、哪一個應用。聽起來很智慧，但誤判時有所聞。
常見的誤判情境包括：某些遊戲使用 UDP 隨機埠，DPI 認不出來，於是被歸類到「其他」或「未知」，反而拿到最低優先權；有些遊戲的登入伺服器與語音伺服器走不同埠，DPI 只認得其中一個，結果遊戲主體被加速、語音卻被限速；更糟的是，某些 VPN 或加密流量會被誤判為 P2P，直接被壓到最低優先。
如果你懷疑是 DPI 誤判，最直接的驗證方式是：把 QoS 改成「以裝置 IP 為準」而不是「以應用程式為準」。也就是說，不要讓路由器去猜哪個是遊戲，而是直接把遊戲主機的 IP 設為高優先，其他一律一般。這樣雖然不夠精細，但至少不會誤傷。對於大多數家庭網路來說，「以裝置為準」的穩定性遠高於「以應用為準」。
（六）與 ISP 的 QoS 打架
還有一個隱形因素：你的 ISP 可能也在做流量管理。某些 ISP 會對特定類型的流量（例如 P2P、串流、遊戲）套用自己的 QoS 政策，而這些政策未必與你家路由器的設定一致。
例如，你在路由器裡把遊戲封包標記為最高優先（DSCP EF），但 ISP 的骨幹設備可能不理會這個標記，甚至把它當成「異常流量」而降級處理。又或者，ISP 對 UDP 流量有整體限速，你再怎麼在自家路由器加速，到了 ISP 端還是一樣排隊。
這種情況很難從家裡端完全解決，但可以緩解：避免在路由器上做過度激進的標記，改用「流量整形 + 公平佇列」的方式，讓封包在自家端不要堆積，而不是試圖說服整條路徑都給你優先權。換句話說，與其跟 ISP 搶優先權，不如讓自己的封包「準時出發」，減少在自家路由器排隊的時間。
四、實戰：如何正確設定遊戲 QoS
講完原理與地雷，接下來是操作流程。以下步驟適用於大多數支援 QoS 的家用路由器，你可以照著做，再依照實測結果微調。
步驟一：先量測真實頻寬
在設定 QoS 之前，先做三件事：
用有線網路連接一台電腦到路由器，關掉其他所有裝置的 Wi-Fi。
假設你測出來下行最小值是 460Mbps、上行最小值是 42Mbps，負載下延遲從 15ms 增加到 120ms。這代表你的線路有明顯的緩衝膨脹問題，QoS 的流量整形會很有幫助。
步驟二：設定合理的頻寬上限
把剛才的實測值打八五折：下行填 390Mbps，上行填 35Mbps。這個數字的目的不是「限制你的網速」，而是「讓路由器在 ISP 緩衝區被塞滿之前就先開始排隊」。聽起來很矛盾，但這是控制延遲最有效的一招。
如果你用的是支援 CAKE 或 fq_codel 的路由器（例如 OpenWrt、部分 ASUS 高階型號），可以直接啟用「智慧佇列」並把頻寬設在上述數值，其餘交給演算法處理。如果你的路由器只有簡單的「優先權」選項，那就手動設定上下行上限，並把優先權規則減到最少。
步驟三：建立正確的優先權規則
以下是建議的優先權配置，從高到低：
一般：瀏覽器、串流影音、視訊會議。
低優先：系統更新、雲端備份、P2P 下載、檔案同步。
關鍵原則：最高優先的裝置不要超過兩台，高優先的流量佔比不要超過總頻寬的三成。與其把遊戲拉高，不如把下載壓低——把「Windows Update」與「iCloud 照片同步」丟到最低優先，往往比把遊戲設為最高優先更有效。
步驟四：驗證與微調
設定完成後，用以下方法驗證：
如果 ping 還是會飆高，把 QoS 的頻寬上限再往下調 10%，重測。
五、不同情境下的設定建議
每個家庭的網路環境不同，以下針對三種常見情境給出建議。
情境一：光纖到府、頻寬充足（500M 以上）、只有一兩個人用。這種情況下，QoS 的效益其實不大，因為線路很少被吃滿。建議只開啟「上行流量整形」，把上行限制在實測值的 85%，其餘保持關閉。這樣可以防止雲端備份突然吃掉上行頻寬，又不會增加不必要的處理負擔。
情境二：第四台寬頻或 ADSL、頻寬 100M 到 300M、家庭成員多。這是 QoS 最能發揮價值的場景。建議完整開啟上下行流量整形，並嚴格設定優先權金字塔。特別注意晚上八點到十一點的尖峰時段，這時候 ISP 端容易壅塞，把自家頻寬上限壓低到實測值的 80% 會很有感。
情境三：使用 5G 固定無線接取（FWA）或行動網路分享。這種線路的延遲本身就不穩定，QoS 的效果有限，但可以減少「自家端」的排隊。建議把上行限制設得比實測值更低（約 70%），並且關閉所有 DPI 類功能，因為行動網路的封包特徵與固網不同，DPI 誤判率更高。
六、結論：遊戲加速不是萬能藥，理解比按鈕重要
回到最初的問題：為什麼「遊戲加速」有時反而變慢？答案其實不複雜——因為多數人把 QoS 當成一個「開了就會變快」的魔法按鈕，但 QoS 本質上是一個「資源分配」工具。它不會變出頻寬，也不會修復線路品質，它只能決定誰先排隊、誰後排隊。當你給錯參數、給錯優先權、或給錯硬體，它就會從交通警察變成塞車製造機。
真正有效的做法，是把 QoS 當成「控制延遲」而不是「提升速度」的工具。先量測真實頻寬，把上限設在實測值的八五折，讓路由器成為排隊的終點而不是起點；然後用最簡單的裝置優先權，把遊戲主機放在金字塔頂端，把下載與備份壓到最底層；最後，如果硬體撐不住或線路本來就很順，那就勇敢地把 QoS 關掉。
記住一個原則：與其讓路由器猜哪個封包是遊戲，不如直接告訴它哪台裝置是遊戲機；與其把遊戲拉高，不如把下載壓低；與其追求帳面上的高頻寬，不如追求穩定的低抖動。這三句話，大概是這篇將近五千字的文章裡，最值得你截圖存下來的一段。
下次當你看到「遊戲加速」那個按鈕時，先別急著按。打開後台，看看頻寬填了多少、優先權給了誰、CPU 使用率長什麼樣子。搞懂這些數字，比任何一鍵加速都來得有用。