RustDesk + Tailscale 遠端桌面延遲最佳化實驗紀錄

前言

最近我在調整一套透過 Tailscale 連接 RustDesk 的遠端桌面環境。原本的目標很單純：看看遠端操作時的延遲還能不能再壓低一點。

這次實驗的重點不是只看 ping，而是把問題拆成三層：

1. Tailscale 是否真的直連，而不是走 DERP relay
2. RustDesk 的畫面流量是否直連，而不是走 relay server
3. 在網路路徑已經健康的情況下，codec、FPS、畫質與音訊設定是否會影響體感

文中的 IP、Peer ID、裝置名稱與私有路徑都已移除或改寫，只保留實驗方法與匿名化結果。

測試環境

測試環境是一台控制端 Mac，連到另一台受控端 Mac。兩端透過 Tailscale 建立私有網路，RustDesk 使用自架 ID/relay server 設定，但實際連線時優先嘗試 peer-to-peer。

受控端當時的遠端桌面解析度是：

1280x800
scale 1.0

這點很重要。遠端桌面的延遲不只看網路，也和實際被編碼的畫面像素數有關。如果表面上看起來是低解析度，但實際輸出仍是 HiDPI 或超高解析度，RustDesk 要編碼的資料量會大很多。

第一步：確認不是 relay 問題

我先確認 Tailscale 連線型態。結果顯示兩端是 direct connection，不是 DERP relay。

接著檢查 RustDesk 的 TCP 連線。結果也顯示 RustDesk 直接連到對端的 Tailscale IP 與動態 port，沒有走 NAS 或 relay server 的 relay port。

也就是說，這次的瓶頸不在「有沒有直連」。

當時的基準網路延遲大約是：

packet loss: 0%
average: 約 34 ms
p95: 約 43 ms
p99: 約 50 ms

這其實已經是很健康的狀態。若遠端桌面仍覺得卡，下一步就應該往影像編碼與 RustDesk 設定去看。

第二步：建立可恢復快照

實驗前先做了一份 RustDesk 設定備份，包含：

• RustDesk 主設定
• peer 個別設定
• codec 快取設定
• 實驗前的連線與延遲基準

這一步很值得做。RustDesk 會在關閉遠端 session 時把 UI 裡的設定重新寫回檔案；如果沒有備份，很容易測到一半忘記原本設定。

第三步：確認可測的 codec

從 RustDesk log 與 Quality Monitor 觀察，這台受控端支援：

H265
VP8
AV1

H264 在這次環境中沒有被回報為可用，因此沒有列入有效測試組。

原本設定是：

codec: auto
actual codec: H265
FPS: 30
quality: balanced / 50
audio: on

測試矩陣

這次主要測三組低負載設定：

H265 / FPS 20 / quality 35 / audio off
VP8 / FPS 20 / quality 35 / audio off
AV1 / FPS 20 / quality 35 / audio off

每組都做以下事情：

1. 關閉目前 RustDesk 遠端 session
2. 修改 peer 設定
3. 重新連線
4. 用 Quality Monitor 確認實際 codec
5. 跑 300 次密集 ping 採樣
6. 記錄平均、P95、P99 與最大值

這裡有一個小坑：如果先修改設定檔，但遠端 session 沒有關閉，RustDesk 可能在關閉時把舊 UI 設定寫回來。後來改成「先關 session，再改設定，再重連」，測試結果才比較乾淨。

測試結果

整理後的結果如下。

設定	實際 codec	平均	P95	P99	最大值	備註
原本設定：auto / FPS30 / balanced 50 / audio on	H265	33.9 ms	43.2 ms	49.6 ms	62.5 ms	純 ping 數字最好
H265 / FPS20 / quality 35 / audio off	H265	34.2 ms	48.2 ms	53.0 ms	59.0 ms	低負載候選
VP8 / FPS20 / quality 35 / audio off	VP8	38.3 ms	48.2 ms	51.6 ms	55.0 ms	可用，但沒有更好
AV1 / FPS20 / quality 35 / audio off	AV1	39.0 ms	49.7 ms	56.4 ms	163.7 ms	有一次明顯尖峰
H265 乾淨重測 / FPS20 / quality 35 / audio off	H265	39.3 ms	48.5 ms	51.2 ms	77.9 ms	後段測試時網路底噪較高

怎麼解讀這些數字

如果只看最早的基準測試，原本設定的數字最好。

但這裡不能直接下結論說「原本設定一定最好」，因為後面測試時網路底噪已經上升。從整體結果看，VP8 和 AV1 沒有明顯改善，AV1 還出現一次較大的延遲尖峰。

H265 則是這套環境中最穩定、最自然的路徑。它原本就是 auto 模式選到的 codec，Quality Monitor 也能確認實際使用 H265。

因此最後我保留的實用設定是：

H265
FPS 20
quality 35
audio off
resolution 1280x800
scale 1.0

這組不一定讓 ping 數字變得更低，但它降低了畫面編碼負載與音訊處理負擔，比較適合追求穩定遠端操作。

這次研究得到的結論

第一，當 Tailscale 已經是 direct，RustDesk 也已經是 peer-to-peer 時，繼續調 relay server 通常不會有太大幫助。

第二，RustDesk 的體感延遲不只取決於網路 ping。解析度、codec、FPS、畫質與音訊都會影響實際操作感。

第三，H265 在這次環境中是最佳保留選項。VP8 能用，但沒有帶來改善；AV1 也能用，但延遲尖峰風險較高。

第四，實驗前一定要備份設定。RustDesk 會自動寫回 peer 設定，沒有備份或固定流程，很容易測到混合狀態。

最終設定

最後保留的設定如下：

codec-preference: h265
custom-fps: 20
image_quality: custom
custom_image_quality: 35
disable_audio: true
show_quality_monitor: false

如果日後要再測，我會優先做兩件事：

1. 針對原本設定與 H265 低負載設定做多輪交叉測試
2. 加入實際操作體感紀錄，例如打字、拖視窗、捲動畫面與切換 App

因為遠端桌面最佳化最後看的不是單一數字，而是「穩定、可預期、手感不拖」。