RustDesk「已連線，等待影像中」完整修復指南

如果 RustDesk 顯示 「已連線，等待影像中」，接著出現黑畫面，好消息是困難的部分其實已經完成：兩端已經找到彼此，連線也已經建立。真正缺少的是 畫面。問題出在遠端主機沒有產生可傳送的螢幕畫面。本文將依序說明所有已知原因，從最常見的狀況一路談到邊緣案例，並針對每一種原因提供具體的解決方法。

簡短結論

連線已經建立，但沒有畫面緩衝區可供擷取。當遠端主機沒有接螢幕、螢幕處於休眠或鎖定狀態，或是作業系統不允許 RustDesk 錄製該顯示器時，視訊串流就沒有任何內容可以編碼。只要讓 RustDesk 能夠擷取到真正、處於喚醒狀態的顯示畫面——不論是透過實體螢幕、HDMI 模擬顯示器插頭、正確的權限，或是相容的編碼格式——畫面就會出現。

從這裡開始：有沒有東西可以擷取？

目前回報最多的原因，是無頭主機（headless machine）——也就是沒有接螢幕、或螢幕處於休眠狀態下運作的伺服器、迷你主機或工作站。由於沒有作用中的顯示器，GPU 不會產生任何畫面緩衝區，因此 RustDesk 雖然連線成功，卻沒有任何內容可以傳送。這個狀況在 RustDesk 的問題追蹤系統中一再出現，包括目標端螢幕關閉時出現黑畫面的回報，以及長期存在的「已連線，等待影像中」討論串。

有三種方式可以讓它有東西可以擷取：

• 接上螢幕，並確認螢幕已經開機且處於喚醒狀態。
• 使用 HDMI（或 DisplayPort）模擬顯示器插頭。 這種價格低廉的轉接頭能讓 GPU 誤以為接了螢幕，進而持續產生畫面緩衝區供 RustDesk 擷取。這是無頭桌上型電腦與家用伺服器的標準解法。
• 在 Linux 上，依照官方文件設定無頭環境。 RustDesk 支援無頭 Linux 環境，但設定方式與一般桌面連線不同——詳見無頭 Linux 支援 wiki。

如果螢幕確實已經接上，那麼下一個可疑對象就是螢幕進入了休眠狀態。

依原因排查修復方法

螢幕休眠、鎖定與螢幕保護程式

如果先前正常運作，主機閒置一段時間後才變成黑畫面，那就是螢幕進入了休眠狀態。

• Windows： 設定電源計畫，讓螢幕與主機在需要遠端存取的時段內都不會休眠，並停用螢幕保護程式（或設定連線期間不需要輸入密碼）。
• macOS： 在需要遠端存取的時段內，避免螢幕進入休眠——可在**「系統設定」→「顯示器」**（或「鎖定畫面」／節能設定）中調整，並讓 Mac 保持接上電源，因為使用電池時的休眠行為會不同。
• Android： 螢幕必須處於開啟狀態才能分享畫面，因此連線前請先觸碰螢幕將其喚醒。從 iOS 連線到螢幕已關閉、處於休眠狀態的 Android 裝置，是一種已知的「等待影像中」情況——請先喚醒目標裝置。

macOS 權限設定

macOS 在未經明確同意的情況下，不允許任何應用程式錄製螢幕。如果 RustDesk 在 Mac 上連線成功卻持續黑畫面，請開啟**「系統設定」→「隱私權與安全性」→「螢幕錄製」**，啟用 RustDesk，然後重新啟動應用程式。黑畫面如果特別發生在登入畫面，就代表 RustDesk 的服務／輔助程式沒有安裝成能在使用者登入前執行——請安裝該元件以支援登入前擷取畫面。

視訊編碼格式不相容

RustDesk 可以用多種方式編碼串流，而預設編碼格式不見得適合每一種遠端硬體。在連線工具列（或設定）中切換編碼格式——VP8、VP9、AV1，或是在硬體支援的情況下使用 H.264/H.265——並觀察畫面是否出現。如果硬體編碼器在特定 GPU 上產生空白畫面，退回使用如 VP9 這類軟體編碼格式，是最可靠的做法。

硬體加速與 GPU 驅動程式

部分 GPU——最常見的是 NVIDIA 相關配置——會與 RustDesk 的硬體加速擷取及算繪路徑產生衝突。以下兩種做法有助於解決問題：

• 關閉硬體編碼器。 在連線工具列（或設定）中，停用**「使用硬體編碼器」**，讓編碼改用軟體路徑進行——這能解決許多有問題的 GPU 上的黑畫面問題。
• 更新 GPU 驅動程式。 在驅動程式或作業系統更新後才出現的黑畫面，通常只要更新到最新版驅動程式就能解決，NVIDIA 硬體尤其如此。

Linux 與 Wayland

在 Linux 上，Wayland 的畫面擷取是透過 PipeWire 與 xdg-desktop-portal 進行的：第一次使用時會跳出提示，要求你同意並選擇要擷取的顯示器——多數情況下系統會記住這項選擇，之後就不會再次提示——且必須在有作用中的登入工作階段內才能運作。這是 Wayland 的安全性設計，因此單靠這個機制無法涵蓋登入畫面（greeter）或真正的無頭主機——不過非互動式的 Wayland 擷取功能目前正在積極開發中（PR #15420）。如果你在 Wayland 上看到空白畫面，通常只要接受 portal 的畫面分享提示，並確認 xdg-desktop-portal 與 PipeWire 已安裝且正在執行即可解決；若是無頭主機，請依照文件中的無頭環境設定進行。若發行版仍提供 X11/Xorg 工作階段，登入該工作階段也能繞過 portal 路徑——但由於愈來愈多發行版轉向僅支援 Wayland，修復 portal/PipeWire 路徑才是更長遠可靠的做法。

網路與中繼伺服器

由於這則訊息本身包含「已連線」字樣，連線通常已經成功建立——但如果中繼伺服器過載，或中繼連接埠遭到封鎖，視訊畫面仍然可能卡住。若使用標準伺服器架構，請確認TCP 21115-21117 與 UDP 21116在兩端之間皆可互通。只有在使用 WebSocket 用戶端時，才需要開放 TCP 21118-21119。公用示範伺服器屬於共用資源，無法保證其傳輸效能，因此如果你每天都仰賴 RustDesk 運作，自架專屬的中繼伺服器能讓運作表現穩定許多。如果連線本身持續中斷、或始終無法建立，那就是另一個問題了——請參閱 RustDesk Server Pro 常見問題。

隨時保持最新版本

舊版本會帶著舊版的擷取相關錯誤。請將主控端與被控端用戶端都更新到最新版本，如果你是自架伺服器，也請一併更新伺服器。許多黑畫面回報案例，只要雙方都完成更新，問題就自然消失了。

開源帶來的優勢

當黑畫面問題已經超出上述檢查清單的範圍時，RustDesk 提供了封閉原始碼工具所沒有的優勢：採用 AGPL 授權條款公開的實際擷取程式碼。你（或委託的技術人員）可以親自閱讀該平台上擷取功能的實作方式、重現問題，並直接針對公開儲存庫提出精確的問題回報——而無需苦等廠商的客服回覆。

伺服器掌握在自己手中，變數自然更少

自行架設專屬的中繼伺服器與 ID 伺服器，就能徹底排除共用公共基礎設施這個變數——在追查擷取問題時，少一個未知因素，並且對於可調整的部分擁有完全的掌控權。這是除了資料掌控之外，另一項容易被忽略的附加價值。