RustDesk 無法連接：如何分辨 ID 服務、中繼及直連？

RustDesk 無法連接時，先確定伺服器部署及最後成功的連接階段。螢幕顯示 ID，未證明遠端電腦可用、存取獲准或中繼能承載工作階段。更改網絡路徑前，先分開這些問題。

關鍵要點：

• 確認兩端使用預期的公共或自行託管服務。
• 分辨 ID 探索、擁有者批准、直連及中繼傳輸。
• 比較獲准路徑時，保留伺服器設定和密鑰。
• 成功測試須有正確桌面及可解釋的連接模式。

本文按所列 RustDesk 客戶端及自行託管官方文件整理，未進行完整端到端實測。記錄兩端客戶端版本及作業系統；選單名稱與可見連接資訊可能有別，版本未清楚顯示模式時，保留「未知」。

RustDesk 無法連接停在哪個階段？

RustDesk 客戶端文件介紹就緒訊息、本機 ID 及連接另一部電腦的輸入欄位；網絡設定亦可指定伺服器和代理。這些觀察各有意思：ID 欄位有內容，並不等於已連接預期的遠端裝置。［1］

最後觀察	下一項調查	須分開的事項
未就緒或 ID 不可用	預期部署及 ID 服務存取	遠端擁有者的工作階段許可
ID 已知但目標不可用	遠端客戶端及正確服務配置	本機是否有 ID
擁有者收到請求但拒絕	身份及獲准工作	網絡路徑修復
直連失敗但中繼正常	實際模式及直連限制	中繼失敗
ID 階段正常但中繼嘗試失敗	同一已配置公網中繼及可用性	是否必須更換伺服器密鑰
桌面開啟但動作受限	工作階段或系統權限	傳輸是否建立

不同應用都失敗時，先採用一般裝置排障流程。這篇只處理既有 RustDesk 部署中的連接階段，不教建立或對外開放新的遠端桌面伺服器。

步驟 1：兩端應使用哪一種伺服器部署？

向部署擁有者確認，客戶端應使用公共基礎設施，還是機構管理的服務，再對照兩部裝置的預期配置。雙方交換的 ID 看似正確，也可能分屬不同服務環境。

1. 記錄存取端與遠端的客戶端版本及作業系統。
2. 確認獲准的 ID 服務及中繼安排，不公開私人伺服器地址。
3. 檢查機構發放的配置或受管理版本是否必須保留。
4. 輸入遠端 ID 前，記錄本機就緒狀態。

官方客戶端指引把 ID、中繼、可選 Pro API 和密鑰分開設定。API 登入失敗，未證明 ID 或中繼失敗。不要把討論區的新配置字串或密鑰貼到現有部署，靠猜測修復連接。［1］

自行託管基礎設施的伺服器配置及客戶端預期密鑰由管理員負責。遇到配置或密鑰不符訊息，先把證據交給擁有者，再考慮路徑比較。公網出口不同，不能證明另一個服務可信。

不要把安裝和伺服器遷移混進這次修復。重新啟動前儲存本機工作；若要重啟遠端客戶端，確認可信人士能在現場恢復。沒有人能接觸的主機，不適合推測性更改配置。

步驟 2：RustDesk ID 伺服器連接是否對應正確目標？

透過可信渠道向擁有者核實遠端 ID。不接受陌生人士突然提出的支援指示、不索取永久密碼，也不改存取方式來繞過擁有者拒絕。目標是已知電腦上雙方同意的工作階段。

遠端電源、網絡、客戶端運行及部署配置，與本機就緒分開檢查。本機有 ID，睡眠中的遠端仍可能無法使用。擁有者無法確認可用性時，保留這項未知，不將每次失敗解釋為中繼故障。

官方自行託管文件區分 hbbs（ID 及會合／信令服務）和 hbbr（中繼服務）。客戶端透過 ID 服務定位目標，再嘗試建立路徑。成功探索目標與成功傳輸桌面工作階段，須分別記錄。［2］

一次獲准嘗試後，保存準確錯誤，註明發生於聯絡目標前、請求送達後，還是開啟桌面的階段。公開截圖遮蔽 ID、密碼、配置字串及私人地址，避免診斷資料洩露存取條件。

兩端本應採用相同部署，但獲准配置不符時，交由管理員核對。不要將一端遷到無關公共服務來「修好」不符；這會改變部署並建立新的信任關係，令測試回答另一問題。

步驟 3：這是直連還是 RustDesk 中繼連接失敗？

官方架構先嘗試以打洞讓兩端直連，失敗後可使用中繼。因此直連失敗，未代表整個工作階段無法建立；ID 查詢成功，亦未證明所需中繼可達。［2］

工作階段開啟後，按客戶端提供的連接資訊記錄實際模式。版本未清楚顯示時，列為未知並向部署擁有者或官方文件求證。低延遲未證明直連，螢幕更新緩慢也未證明經過中繼。

VPN 可以改變路由及 NAT 穿越面對的條件，因此應量度結果，不承諾直連更可靠。原本直連失敗，而同一獲准工作階段後來經中繼建立，記錄這項分別，不聲稱打洞已修復。

自行託管服務的傳輸錯誤，連同階段及時間交給管理員。官方文件列出 ID 和中繼不同職責及多種部署方式，要求屬於實際伺服器安排，不是讓用戶在家用路由器開放所有入站連接埠。［2］

有關聯時檢查既有獲准代理，Windows 代理作用範圍說明可協助分辨系統設定與應用行為。不移除機構代理、不關閉 TLS 驗證，也不換伺服器密鑰來使路徑比較看來成功。

如果對方使用 Android 手機並需要協助，Android 有人在場遙距協助指南說明如何分開查看與輸入權限，以及如何結束工作階段。

步驟 4：比較同一獲准公網中繼的存取路徑

部署和授權已確認、遠端客戶端可用，而證據指向已獲准公網中繼的存取問題，才採用這個分支。只經機構私人網絡可達的中繼，需要機構既有接入方法，消費 VPN 不會建立私人網絡入口。

在受支援的 Windows 存取電腦，AethoVPN 可為既有中繼嘗試提供另一條向外路徑。安裝官方 Windows 套件，使用 Pro 或 Premium，選一個目前可用的就近位置並開啟全局模式。ID 服務、中繼地址、伺服器密鑰、目標 ID 及遠端保持不變，同時記錄最終工作階段採用直連還是中繼。

1. 在原本獲准路徑嘗試一次，記下最後成功階段。
2. 連接所選位置，按照VPN 路徑驗證步驟檢查連接。
3. 比較公網地址時，用出口 IP 查詢，再重複原 RustDesk 嘗試。
4. 詢問擁有者請求有否送達，驗證桌面中的約定工作。
5. 客戶端可提供模式時記錄；沒有有用證據便斷開，恢復原本獲准路徑。

此方法不會提供遠端同意、不保證 NAT 打洞、不修復密鑰不符，亦不更改機構部署。如剩餘工作正是獲准公網中繼的比較，可用電郵開始 3 天免費 Pro 試用；每名用戶僅一次，試用在註冊時開始。

macOS 比較須經官方設定指引取得配置，以 VPN 客戶端連接，並使用 Pro 或 Premium。Linux 產品支援限 Debian/Ubuntu x64 的 .deb 安裝包。

另一條路徑成功，能得出的結論有限：存取端向外路徑改變時，這次工作階段表現不同。模式亦改變時要一併記錄；成功嘗試若採用另一種傳輸模式，不能將改善只歸因於中繼可達性。

步驟 5：驗證獲准工作階段並解釋模式

與擁有者確認正確遠端桌面，只完成約定的低影響動作。工作階段開啟但動作受限，核對客戶端或作業系統權限。不要為完成測試而換憑證或給予持續無人值守存取。

記下一條簡短過程：本機就緒、目標核實、擁有者回應、桌面可見、獲准動作及實際模式。模式未知仍是結果中的限制，不能用 ID 欄位取代正確裝置上的操作驗證。

AnyDesk 連接階段排查說明授權為何與服務存取獨立。其連接埠和本機探索要求不適用於 RustDesk，只協助判斷，不當成配置步驟。

測試後正常關閉工作階段，確認擁有者可繼續工作。還原臨時獲准網絡變更，保留原部署配置；私人診斷記錄留下，方便日後相同階段再失敗時比較。

兩條獲准路徑均在相同階段失敗，可提交版本、時區、部署類型、錯誤片段及觀察到的模式；模式未知則解釋原因。不要在公開問題貼出密鑰、密碼、完整配置、私人中繼地址或遠端桌面截圖。

總結

• 更改存取設定前確定預期部署。
• 經可信渠道核實 ID 及遠端可用性。
• 分開處理探索、直連、中繼及權限。
• 只比較已獲准的公網服務路徑。
• 完成約定桌面工作並記錄實際模式。

常見問題

RustDesk 有 ID 便證明遠端可達嗎？

不證明，本機 ID 只是其中一項觀察。核對目標、擁有者確認的可用性和預期部署後，才判斷失敗是否屬中繼或遠端主機。

不同伺服器部署的客戶端可直接使用同一 ID 嗎？

不要假定可定位預期裝置。請部署擁有者核對兩端獲准配置；將一個客戶端改到其它伺服器屬遷移，不是受控網絡測試。

直連失敗是否必然無法遠端存取？

不必然，文件描述的架構可在直連失敗後採用中繼。記錄實際模式，把可用中繼工作階段與 NAT 打洞成功分開。［2］

連接逾時應換伺服器密鑰嗎？

不要推測性更換。逾時與密鑰不符是不同觀察；伺服器擁有者須確認可信配置，測試期間換密鑰會破壞比較，也可能引入信任問題。

VPN 比較為何可能改變連接模式？

路徑有變後，路由和 NAT 條件可能不同。記錄客戶端提供的直連或中繼模式，沒有相應觀察時，不聲稱 VPN 改善打洞或中繼存取。

甚麼能證明 RustDesk 恢復？

已知擁有者批准存取、預期桌面出現且約定工作完成。亦須記錄模式或交代未知原因；只見 ID 欄位未構成恢復證據。

何時由部署管理員接手？

密鑰或伺服器不符、需要私人網絡、政策限制、遠端不可用，或受控獲准路徑持續失敗時，提交遮蔽敏感資料的階段記錄，不自行更改共享基礎設施。

來源:

1. RustDesk Client — https://rustdesk.com/docs/en/client/
2. Self-host — https://rustdesk.com/docs/en/self-host/

Sources checked 2026 年 10 月 7 日.

---

延伸閱讀:

• 對比 RustDesk 與 AnyDesk 的連接階段
• 排查中繼伺服器前先確認 VPN 路徑
• 核對兩端 RustDesk 電腦的 Windows 代理