大多數延遲指南都從「重新啟動路由器」開始。這裡是我們以毫秒為單位量測的七個修正方法，由以打造原生遠端桌面為業的團隊撰寫。
延遲從哪裡來
遠端桌面延遲，就是「這感覺就像我真正的電腦」與「這根本無法使用」之間的差距。如果游標落在觸控板後面、按鍵很晚才到，或是畫面看起來像 2005 年的視訊聊天，代表延遲預算已經在六個步驟的管線中的某處被用光了。
我們打造的是原生遠端桌面 Remio，所以我們花了多到不好意思的時間在量測這條管線。每次連線中都會出現三類延遲：
- 網路延遲。兩台裝置之間的來回時間。最大的單一變數。
- 編碼與解碼延遲。主機壓縮影格、用戶端解壓縮所花的時間。
- 繪製延遲。用戶端 App 把解碼後的像素顯示到螢幕上所花的時間。
大多數指南只處理網路延遲。編碼與繪製往往同樣耗時，尤其是在沒有使用硬體加速的 App 上。以下七個修正方法涵蓋這三個層面，依每個方法能追回多少毫秒來排序。
七個修正方法，依序排列
嚴重程度反映的是該修正能消除多少延遲，而不是套用起來有多難。快速見效的方法放在最後，最後再套用，但不要跳過它們。
01 · 讓主機改用有線乙太網路
關鍵 症狀：游標卡頓，畫面每隔幾秒就撕裂
只要網路線拉得到，主機就不應該使用 Wi-Fi。Wi-Fi 在狀況好的日子也會增加 5 到 30 毫秒的延遲，而封包遺失的尖峰正是造成明顯卡頓的原因，任何軟體設定都藏不住。一個 USB-C 或 Thunderbolt 乙太網路轉接器大約十五美元，卻比你能送出的任何編碼器調校消除更多延遲。在用戶端這點比較不重要，但如果你為了遊戲或音樂製作在追求每一毫秒，也把它接上。
降低主機連線 10 到 25 毫秒的來回延遲，並消除造成明顯卡頓的封包遺失尖峰。
02 · 啟用硬體影像編碼
關鍵 症狀：CPU 明顯發燙，串流時風扇轉速升高
這就是可接受的遠端桌面與出色的遠端桌面之間的差別。硬體編碼讓影格經過你 GPU 專用的影像區塊，而不是 CPU。它更快、更省電，並且在相同位元率下產生更好的畫質。請確認你的遠端桌面 App 已啟用它：
- NVIDIA：NVENC，表現出色且廣泛支援
- AMD：Windows 上的 AMF，Linux 上的 VCE
- Intel：Quick Sync Video
- Apple Silicon：VideoToolbox（Remio 在 Mac 上使用的）
如果你目前的 App 只支援軟體編碼，光是這一點就足以成為換掉它的理由。
編碼時間從 10 到 30 毫秒（軟體）降到 2 到 5 毫秒（硬體）。
03 · 優先使用直接連線，而非中繼伺服器
關鍵 症狀：連線階段資訊顯示「中繼」而非「直連」
當兩台裝置透過中繼伺服器連線時，每個封包都得繞路：用戶端到中繼再到主機。依中繼站所在位置，這段繞路可能增加 30 到 100 毫秒。直接的裝置對裝置連線，則是在兩台機器之間直接傳送資料。在同一個區域網路上，這意味著約 8 毫秒的處理延遲。許多以瀏覽器為基礎的工具會把一切都經由它們的雲端伺服器傳送，從不提供直接路徑。請查看連線面板：如果它顯示中繼，那就是你延遲的來源。
Remio 預設直接連線，只有在嚴格的公司防火牆或特殊的網路配置讓直接路徑不可能時，才會退回中繼。
消除 30 到 100 毫秒的中繼繞路。區域網路直連的連線約為 8 毫秒的處理延遲。
04 · 改用 5 GHz Wi-Fi 或 Wi-Fi 6E
中等 症狀：用 Wi-Fi 很遲鈍，用乙太網路卻正常
如果確實無法使用有線連線，至少確認兩台裝置都在 5 GHz 頻段上。2.4 GHz 頻段與微波爐、藍牙、嬰兒監視器，以及你鄰居的物聯網小玩意共用，簡直一團壅塞。5 GHz 提供更低的延遲、更高的傳輸量與更少的干擾。代價是涵蓋範圍較短，但使用遠端桌面時你通常和路由器在同一個房間。如果路由器支援 Wi-Fi 6 或 6E，請開啟它。OFDMA 與目標喚醒時間功能在擁擠的環境中確實有幫助。
消除 5 到 15 毫秒的 Wi-Fi 抖動，以及最糟的空中時間爭用。
05 · 讓串流解析度符合你所使用的螢幕
中等 症狀：網路良好，但編碼器正在降低畫質或讓影格排隊
以完整解析度串流 4K 螢幕，傳輸的資料量大約是 1080p 的四倍。如果網路跟不上，編碼器不是降低畫質，就是讓影格排隊，兩者都會讓人感覺是延遲。請在 App 設定中降到 1080p 或 1440p。在 13 吋 iPad 或筆電螢幕上，你看不出差別，但延遲預算會看得出來。如果 App 支援，請降低主機的螢幕解析度，而不只是縮小串流，這樣也能減少主機 GPU 的工作量。
從 4K 降到 1080p 時，約釋放 75% 的像素傳輸量。
06 · 使用原生用戶端，而非瀏覽器分頁
關鍵 症狀：使用以瀏覽器或 Electron 為基礎的用戶端
以瀏覽器為基礎的遠端桌面工具，例如 Chrome Remote Desktop、TeamViewer 與 AnyDesk 的網頁用戶端，會增加整整一層額外負擔。瀏覽器必須解碼影像，再透過瀏覽器的繪製管線合成，然後交給作業系統顯示。這會多出一到三個影格的延遲，在 60 fps 下就是 16 到 48 毫秒。
原生用戶端則是使用各平台原生的圖形層，直接解碼到 GPU。影格經過硬體解碼器、GPU，然後到螢幕，沒有任何中間步驟。這就是為什麼 Remio 在每個平台上都是 100% 原生的 App，使用各平台自己的介面框架。沒有 Electron，沒有網頁檢視，沒有跨平台抽象層。
在 60 fps 下，消除 16 到 48 毫秒的瀏覽器合成延遲。
07 · 讓兩端的背景 App 安靜下來
快速見效 症狀：延遲感覺不固定，白天會出現尖峰
這聽起來顯而易見，但一直被低估。在主機上，每個耗用 CPU 或 GPU 的 App 都在搶編碼器的運算週期。在用戶端，每個搶頻寬的 App 都在搶串流的餘裕。常見的嫌疑對象：
- 雲端同步：Dropbox、OneDrive、iCloud 在背景上傳
- 系統更新：Windows Update 與 macOS 更新在無聲無息中下載
- 串流 App：Spotify、YouTube 分頁，任何會用到網路的東西
- 備份：Time Machine、Backblaze、排程的 cron 工作
在開始連線之前先暫停雲端同步與備份，結束後再恢復。
在背景尖峰時追回 5 到 20 毫秒，並避免那種比穩定延遲更難受的隨機抖動。
為什麼 Remio 天生就快
我們不是先做出 Remio，再想辦法讓它變快。我們從第一天起，就為堆疊中的每一層挑選能消除延遲的方案：
- 每個平台都使用硬體加速編碼：編碼時間 2 到 5 毫秒，而不是 20 到 30 毫秒。
- 預設採用裝置對裝置直連：兩台機器之間的直接路徑，沒有中繼繞路。
- 原生 GPU 繪製：解碼後的影格直接送到螢幕。
- 沒有瀏覽器層：網頁繪製引擎的額外負擔為零。
- 自適應位元率：畫質即時依網路調整，影格永遠不會排隊。
在使用乙太網路的區域網路上，Remio 內部量測約 8 毫秒的處理延遲（其餘是你的顯示器自己的 60 Hz 更新節奏），你的輸入會在下一個影格繪製之前就到達。在一般家用 Wi-Fi 上，這個數字落在 25 到 40 毫秒之間。兩者感覺都像是坐在真正的機器前面。
連線前檢查清單
在下次遠端連線之前，先逐項檢查。每個勾選項都對應上述七個修正方法之一。
- 主機使用乙太網路：至少也要是 5 GHz Wi-Fi。
- 已開啟硬體編碼：在 App 的設定中確認。
- 已暫停雲端同步：Dropbox、OneDrive、iCloud。
- 串流解析度合理：除非你有超高速網路，否則使用 1080p 或 1440p。
- 連線類型為直連：而不是中繼。
- 沒有大型下載或備份：延到連線結束後再進行。
- 使用原生 App：而不是瀏覽器分頁。
七項全部做到，你就能消除大多數人所遇到延遲的大約 80%。剩下的 20% 是網際網路路由，唯一的解法是把主機放得離你更近，或者在延遲真的很重要時，讓連線留在區域網路上。
最好的遠端桌面，是讓你忘記它是遠端的那一個。
如果做完這份清單上的每個修正後延遲仍然存在，瓶頸很可能就是 App 本身。免費試用 Remio，不需帳號、不需信用卡，只要一組 PIN 就能連線。你可能會驚訝，原來許多緩慢是出在軟體，而不是網路。
最後更新：2026 年 5 月。隨著編碼器、網路與作業系統演進，我們會持續更新這份指南。
