RustDeskの「Connected, waiting for image」を完全解決するガイド

RustDeskで**「Connected, waiting for image」**と表示され、その後に黒い画面が出る場合、朗報なのは、難しい部分はすでにクリアできているということです。つまり、両端末が互いを見つけ出し、セッションはすでに確立されています。足りていないのは画像だけです。リモートマシン側の何かが、送信すべき画面イメージを生成できていないのです。このガイドでは、最もよくある原因からエッジケースまで、判明しているすべての原因と、それぞれの具体的な対処法を順に解説します。

結論から言うと

セッションは接続されていますが、キャプチャすべきフレームバッファが存在しません。リモートマシンにモニターが接続されていない、ディスプレイがスリープ・ロック状態になっている、またはOSがRustDeskによる記録を許可していないディスプレイである場合、映像ストリームにはエンコードする対象がありません。モニター、HDMIダミープラグ、適切な権限、対応コーデックなど、RustDeskが実際にキャプチャできる稼働中のディスプレイを用意すれば、画像は表示されるようになります。

まず確認すべきこと:そもそもキャプチャする対象はあるか?

圧倒的に多く報告されている原因はヘッドレスマシンです。モニターが接続されていない、またはディスプレイがスリープ状態のまま稼働しているサーバー、ミニPC、ワークステーションなどが該当します。アクティブなディスプレイが存在しない場合、GPUはフレームバッファを生成しないため、RustDeskは接続はできても送信するデータがありません。このパターンはRustDeskのIssueトラッカーで繰り返し報告されており、対象機のモニターがオフのときに限って黒画面になるという報告や、長期にわたる「Connected, waiting for image」スレッドなどが挙げられます。

キャプチャする対象を用意する方法は3つあります。

• モニターを接続する — 電源が入っており、スリープしていない状態を確認してください。
• HDMI(またはDisplayPort)ダミープラグを使用する — この安価なアダプターは、GPUにディスプレイが接続されていると認識させるため、RustDeskが取得できるフレームバッファを描画し続けます。ヘッドレスデスクトップやホームサーバーにおける標準的な対処法です。
• Linuxではドキュメント化されたヘッドレス構成を利用する — RustDeskはヘッドレスなLinux構成をサポートしていますが、通常のデスクトップセッションとは設定が異なります。詳しくはHeadless Linux Support wikiを参照してください。

モニターがすでに接続されている場合、次に疑うべきはスリープ状態に入っていることです。

原因別の対処法

画面のスリープ、ロック、スクリーンセーバー

以前は動作していたのに、マシンがアイドル状態になった後で黒画面になった場合、ディスプレイがスリープに入っています。

• Windows: リモートアクセスが必要な時間帯はディスプレイとマシンがスリープしないよう電源プランを設定し、スクリーンセーバーを無効化してください(またはセッション中にパスワードを要求しないよう設定します)。
• macOS: リモートアクセスが必要な時間帯はディスプレイがスリープしないようにします。システム設定 → ディスプレイ(またはロック画面/エネルギーの設定)で設定し、バッテリー駆動時はスリープの挙動が異なるため、Macは電源アダプターに接続したままにしてください。
• Android: 画面がオンになっていないと共有できないため、接続前にディスプレイをタップして起動させてください。画面がオフでスリープ中のAndroid端末にiOSから接続するケースは、「waiting for image」の既知の事例として報告されています。まず対象端末を起動させてください。

macOSの権限設定

macOSは、明示的な同意がない限り、どのアプリにも画面収録を許可しません。Mac上でRustDeskが接続はするものの黒画面のままになる場合は、システム設定 → プライバシーとセキュリティ → 画面収録を開いてRustDeskを有効にし、アプリを再起動してください。特にログイン画面で黒画面になる場合は、ユーザーがログインする前に実行されるRustDeskのサービス/ヘルパーがインストールされていないことを意味します。ログイン前のキャプチャに対応させるため、これをインストールしてください。

映像コーデックの不一致

RustDeskは複数の方式でストリームをエンコードできますが、デフォルトの設定が必ずしもリモート側のハードウェアに適しているとは限りません。セッションツールバー(または設定)でコーデックを切り替えてみてください——VP8、VP9、AV1、またはハードウェアが対応していればH.264/H.265——そして画像が表示されるか確認します。特定のGPUでハードウェアコーデックが空白の画像しか出力しない場合は、VP9のようなソフトウェアコーデックに戻すのが確実な対処法です。

ハードウェアアクセラレーションとGPUドライバー

一部のGPU(最も報告が多いのはNVIDIA構成)は、RustDeskのハードウェアアクセラレーションによるキャプチャ/レンダリング処理と競合します。有効な対処法は2つあります。

• ハードウェアコーデックをオフにする。 セッションツールバー(または設定)でハードウェアコーデックを使用を無効にし、エンコード処理をソフトウェア方式にフォールバックさせます。これにより、多くの問題のあるGPUで黒画面が解消します。
• GPUドライバーを更新する。 ドライバーやOSの更新後に発生し始めた黒画面は、最新のドライバーに更新することで解決するケースが多く、特にNVIDIA製ハードウェアで顕著です。

LinuxとWayland

Linuxでは、Waylandの画面キャプチャはPipeWireとxdg-desktop-portalを経由します。初回はディスプレイを選択するための同意プロンプトが表示されますが——多くの場合その選択は記憶されるため、以降は再表示されません——アクティブなログインセッション内であれば動作します。これはWaylandのセキュリティ設計によるものであり、それ単体ではグリーター画面や完全にヘッドレスなマシンには対応しません(ただし、無人でのWaylandキャプチャは現在活発に開発が進められています。PR #15420)。Waylandで画面が空白になる場合、通常はポータルの画面共有プロンプトを承認し、xdg-desktop-portalとPipeWireがインストールされて実行されていることを確認すれば解決します。ヘッドレスなマシンでは、ドキュメント化されたヘッドレス構成を利用してください。ディストリビューションがまだX11/Xorgセッションを提供している場合は、それにログインすることでもポータル経由の処理を回避できます——ただし、多くのディストリビューションがWayland専用へと移行しつつある中では、ポータル/PipeWire側の問題を解決しておくほうが、より将来性のあるアプローチと言えます。

ネットワークとリレー

このメッセージには「connected」という単語が含まれているため、セッション自体はすでに確立されていることがほとんどです。ただし、リレーが過負荷状態にあったり、リレーポートがブロックされていたりすると、映像だけが停止することがあります。標準的なサーバー構成では、TCP 21115-21117とUDP 21116が両端末間で疎通していることを確認してください。WebSocketクライアントを使用する場合のみ、TCP 21118-21119を開放します。パブリックのデモサーバーは共有リソースであり、スループットは保証されていません。RustDeskを日常的に利用しているのであれば、自分自身のリレーをセルフホスティングすることで、はるかに安定した動作が得られます。セッション自体が切断される、またはそもそも確立されない場合は別の問題です。RustDesk Server Pro のよくある質問を参照してください。

常に最新の状態を保つ

古いビルドには、古いキャプチャ関連のバグがそのまま残っています。操作する側とされる側の両方のクライアントを最新リリースに更新し、セルフホストしている場合はサーバーも更新してください。両端末を更新するだけで解消する黒画面の報告も少なくありません。

オープンソースならではの強み

このチェックリストを試しても黒画面が解決しない場合でも、RustDeskにはクローズドソース製品にはない強みがあります。それは、AGPLライセンスの下で公開されている実際のキャプチャコードです。あなた自身(または委託先のエンジニア)が、お使いのプラットフォームでキャプチャがどのように動作しているかを直接コードで確認し、問題を再現したうえで、ベンダーのサポート対応を待つことなく、公開リポジトリに対して正確な報告を提出できます。

サーバーを自分で管理すれば、変数はもっと少なくなる

自分自身のリレーとIDサーバーを運用すれば、共有のパブリックインフラという要素そのものがなくなります。キャプチャの問題を追いかけているときに不確定要素が一つ減るだけでなく、調整可能な部分をすべて自分でコントロールできるようになります。これは、データを自社で保持できることに加えた、地味ながら確かなメリットです。