追求極致遠端桌面體驗：RustDesk、Tailscale、自架 NAS 與真實延遲優化紀錄

遠端桌面這件事，很多人一開始只在意「能不能連上」。但當你真的每天使用遠端電腦工作，需求很快就會變成另一件事：

不是能不能連，而是能不能像坐在那臺電腦前面一樣順。

這篇文章整理我們實際測試與優化的過程。受控端是 Mac mini，控制端是外網 MacBook Pro，中間搭配自架 RustDesk server 與 Tailscale，目標是把遠端操作延遲壓到可長時間工作的程度。

硬體架構

我們的環境由三個主要角色組成：

控制端：MacBook Pro
受控端：Mac mini
伺服器：NAS，主機名 NAS 主機名已遮蔽

Mac mini 是真正被遠端操作的電腦。

MacBook Pro 是外網使用者實際操作的設備。

NAS 則負責自架 RustDesk server。

這裡很重要的一點是：NAS 並不是實際傳輸畫面的核心瓶頸。在我們的測試中，RustDesk 影像流量實際上是 MacBook Pro 與 Mac mini 直連，NAS 主要負責 ID / rendezvous，也就是協助雙方找到彼此。

軟體架構

我們使用兩個核心工具：

RustDesk：遠端桌面軟體
Tailscale：建立跨網路的私有內網

RustDesk 負責遠端桌面畫面、鍵盤滑鼠、剪貼簿等功能。

Tailscale 則負責讓 MacBook Pro、Mac mini、NAS 即使在不同網路，也像在同一個內網裡一樣互相連接。

我們的 RustDesk server 自架在 NAS 上：

NAS 主機名已遮蔽

Mac mini 的 RustDesk 設定使用 NAS 的 Tailscale IP 作為 rendezvous / relay server。這樣外網不需要直接暴露 NAS 公網服務，也不用完全依賴 RustDesk 官方基礎設施。

與 AnyDesk 等商用遠端軟體的本質差異

AnyDesk、TeamViewer、Chrome Remote Desktop 這類工具最大的優點是方便。安裝、登入、輸入 ID，通常就可以用了。

但方便的代價是：你很難完全掌握流量路徑。

一般商用遠端軟體可能會經過：

官方帳號系統
官方 rendezvous server
官方 relay server
官方 NAT traversal infrastructure

如果雙方無法直連，畫面流量可能會經過官方中繼伺服器。這不一定不好，但對追求極致延遲、可控性、隱私與可診斷性的人來說，就少了一層掌控。

我們這套架構的差異是：

RustDesk server 自架在自己的 NAS
Tailscale 建立自己的私有網路
實際遠端畫面盡可能走 direct peer-to-peer

也就是說，我們不是隻相信「軟體說已連線」，而是實際檢查：

RustDesk 是否直連
Tailscale 是否 direct
是否有走 DERP / relay
延遲是否穩定
解析度與編碼量是否合理

是否經過第三方伺服器轉接？

這要分成「控制層」與「資料層」來看。

Tailscale

Tailscale 通常會使用官方 coordination server 來做身份驗證、節點發現與連線協調。

但在我們測試中，資料流量是 direct：

Mac mini -> MacBook Pro: direct

這代表真正的遠端資料流量沒有經過 Tailscale DERP relay。

如果 Tailscale 顯示 DERP，代表流量走了中繼，延遲通常會比較高。

但我們看到的是 direct，因此 Tailscale 不是主要瓶頸。

RustDesk

RustDesk server 架在自己的 NAS 上。NAS 主要負責讓兩端找到彼此。

我們實際檢查連線後看到：

Mac mini RustDesk -> MacBook Pro RustDesk: ESTABLISHED direct TCP

也就是說，RustDesk 畫面流量沒有經過 NAS relay。

所以我們這次的結論是：

控制層可能會用到 Tailscale 官方協調服務
資料層沒有走 Tailscale DERP
RustDesk 畫面流量沒有走 NAS relay
RustDesk 也沒有走官方 relay

如果要讓控制層也完全自管，未來可以研究 Headscale 取代 Tailscale 官方 coordination server。

我們的目的

我們的目標不是單純「連得上」，而是：

外網 MacBook Pro 操作內網 Mac mini
延遲穩定
畫面夠清楚
滑鼠鍵盤反應接近本地
流量路徑可理解、可驗證、可調整

這裡的重點是「可驗證」。

我們不是憑感覺調整，而是逐步檢查：

Tailscale status
Tailscale ping
ICMP ping
RustDesk log
RustDesk 實際連線 socket
RustDesk encoder 解析度
FPS
畫質
音訊是否關閉
是否使用 relay

最初的問題：不是連不上，而是延遲飄

一開始 MacBook Pro 使用手機熱點連線。Tailscale 顯示 direct，看起來沒有繞路，但延遲仍然明顯飄動。

手機熱點時，我們曾測到：

平均延遲：約 292ms
最高延遲：約 906ms
封包遺失：0%

這代表問題不是斷線，而是 jitter 太大。

封包沒有掉，但延遲忽高忽低。對遠端桌面來說，這比單純平均延遲高更痛苦，因為滑鼠和畫面會出現不穩定的黏滯感。

關鍵改善：改用有線分享網路給 MacBook Pro

後來我們讓 MacBook Pro 使用有線連接分享網路。這一步改善非常明顯。

一分鐘測試結果：

60 packets transmitted
60 packets received
packet loss = 0.0%

min/avg/max/stddev =
33.790 / 41.998 / 57.267 / 4.705 ms

這代表：

平均延遲：約 42ms
最高延遲：57ms
抖動非常低
無掉包

這是遠端桌面非常健康的網路品質。

這也證明瞭：之前最大的瓶頸不是 RustDesk，不是 NAS，也不是 Tailscale，而是手機熱點的無線段抖動。

解析度：HiDPI 很漂亮，但會讓編碼量暴增

macOS 的 HiDPI 模式很舒服，字體漂亮、畫面銳利。

但對遠端桌面來說，HiDPI 有一個問題：

你看到的 UI 可能是 1152x720，但 RustDesk 實際編碼可能是 2304x1440。

也就是：

UI Looks like: 1152 x 720
Actual encoded resolution: 2304 x 1440

實際像素量是：

2304 x 1440 = 3,317,760 pixels

改成非 HiDPI 後：

1152 x 720 = 829,440 pixels

畫面資料量直接少約 75%。

後來我們選擇折衷：

1280x800 scaling:off

這樣實際編碼量是：

1280 x 800 = 1,024,000 pixels

比 1152x720 多一點操作空間，但仍遠低於 HiDPI 的雙倍像素輸出。

RustDesk 設定：FPS、畫質、音訊

我們最後調整到偏低延遲的組合：

解析度：1280x800 scaling:off
FPS：20
畫質：約 35
音訊：關閉
編碼：H.265 / hevc_videotoolbox
連線：direct

FPS 從 25 降到 20，不會讓 ping 變低，但會降低 RustDesk 每秒需要編碼與傳輸的畫面數量。

畫質從約 40 降到 35，也可以降低畫面資料量。

音訊關閉則可以減少 session 裡的即時資料流。音訊本身頻寬不大，但對追求低延遲的人來說，能少一個即時同步項目就是少一個變因。

H.265 vs VP8 是什麼意思？

RustDesk 傳畫面時，要把桌面壓縮成影片串流。這個壓縮格式就是 codec。

目前我們使用的是：

H.265 / hevc_videotoolbox

H.265 的特色是：

優點：壓縮效率好、省頻寬、畫質好
缺點：編碼/解碼可能比某些 codec 多一點延遲

VP8 的特色是：

優點：有時體感延遲更低
缺點：比較喫頻寬

因為我們現在網路已經很穩，未來可以測 VP8。

重點不是看 ping，因為 ping 只測網路往返，不包含：

畫面擷取
編碼
傳輸
解碼
螢幕顯示

所以即使 ping 一樣，H.265 和 VP8 的體感仍可能不同。

目前體感等級

以我們的一分鐘測試來看：

P50: 41.8 ms
P75: 44.4 ms
P90: 48.1 ms
P95: 50.2 ms
P99: 53.8 ms
Max: 57.3 ms

這個網路品質對外網遠端桌面來說已經很好。

如果用比較口語的方式描述：

網路層延遲：前段班
穩定度：很高
遠端桌面整體體感：已經接近可長時間工作的程度

但遠端桌面總延遲不只包含網路。真正從滑鼠操作到畫面更新，還會包含 macOS 畫面產生、RustDesk 擷取、編碼、解碼、顯示更新。

所以整體體感仍可能高於 42ms。

還能優化什麼？

目前網路已經不是主要瓶頸，下一步應該優化 Mac mini 畫面產生與 RustDesk 編碼。

1. 關閉 macOS 動畫與透明效果

Mac mini 端可以降低視覺變化量：

defaults write com.apple.Accessibility ReduceMotionEnabled -bool true
defaults write com.apple.Accessibility ReduceTransparencyEnabled -bool true
defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool false

這不會降低 ping，但會讓 RustDesk 更容易壓縮畫面，尤其是切換視窗、開關 App、透明側欄、模糊背景等場景。

2. 關閉 RustDesk file transfer

如果不需要檔案傳輸，可以關閉。

這不一定會明顯降低延遲，但能讓 session 更單純。

3. 測試 VP8

在目前網路穩定的情況下，可以比較：

H.265：省頻寬
VP8：可能體感更直接

測試方式不是隻看 ping，而是實際操作：

滑鼠移動
打字
拖視窗
切換 App
捲動網頁
開 Terminal

4. 若追求極限，回到 1152x720

目前 1280x800 是舒服折衷。

如果真的要壓到最低延遲，可以回到：

1152x720 scaling:off

代價是操作空間變小。

5. 未來可研究 Headscale

目前 Tailscale 的 coordination 層仍使用官方服務。

如果想讓控制層也完全自管，可以研究 Headscale。

不過要注意：這不一定會降低資料延遲。

因為目前資料層已經是 direct，Headscale 主要改善的是自主性，而不是一定讓畫面更快。

最終建議設定

如果目標是「穩定、低延遲、可長時間工作」，目前推薦：

Mac mini:
1280x800 scaling:off
關閉動畫
關閉透明效果

RustDesk:
FPS 20
畫質 35
音訊關閉
H.265 先保留
確認直連

Tailscale:
確認 direct
避免 DERP relay

網路:
MacBook Pro 優先使用有線分享
避免純手機熱點 Wi-Fi

結論

這次最大的收穫是：遠端桌面延遲不是單一因素造成的。

它是一條完整鏈路：

控制端網路
Tailscale 連線方式
RustDesk 是否直連
受控端解析度
macOS 畫面產生
RustDesk 編碼
控制端解碼
螢幕顯示

我們一開始以為問題可能在 RustDesk、NAS 或 Tailscale。

但實測後發現，最大的問題其實是手機熱點的無線抖動。

當 MacBook Pro 改用有線分享網路後，延遲從偶爾數百毫秒，穩定到約 42ms，且 1 分鐘測試沒有掉包。

這也說明一件事：

追求極致遠端桌面體驗，不是一直換軟體，而是把整條路徑拆開，一段一段驗證。

當你知道流量怎麼走、畫面怎麼編碼、延遲在哪裡發生，你纔有辦法真正優化，而不是盲目猜測。