自宅回線を事業者変更したあと、開発用の Hyper-V ゲストへ RDP しようとすると、突然 0x204 で弾かれるようになりました。
ゲストのコンソールには入れる。Ping も怪しい。なのに RDP だけ死んでいる、という中途半端な状態です。
先に、やったことだけ書きます
結論から書きます。今回効いたのは次の 1 行です。
Set-NetConnectionProfile -InterfaceAlias "vEthernet (外部スイッチ)" -NetworkCategory Private
ルーターや回線を変えると、Windows が Hyper-V 側の仮想 NIC を 新しいネットワーク（Public） として認識し直すことがあります。
Public のままでは、RDP まわりのファイアウォール規則が厳しく残る。サービスは動いているのに届かない、という見え方になります。
ただし、いきなりプロファイルを触るのはおすすめしません。次の順番で「生きている層」を潰してから直すと、遠回りが減ります。
1. Hyper-V コンソールでゲストに入れるか
2. Ping（ICMP だけだと嘘をつくことがある）
3. ゲスト側 ipconfig / ゲートウェイ到達
4. netstat で 3389 LISTENING
5. Get-NetConnectionProfile（Public / Private）
6. Test-NetConnection -Port 3389
7. 必要なら NetworkCategory を Private へ
何が起きたか
光回線の事業者変更と同時に、自宅ルーターを Deco 系のメッシュへ載せ替えました。
回線そのものは使える。ホストの Windows 11 Pro も普通にネットに出る。それなのに、開発用の Hyper-V ゲストだけ RDP が落ちた。
エラーは 0x204。メッセージを見ると「リモート コンピューターに接続できません」系で、だいたい「届いていない or 拒否されている」のどちらかです。
構成の骨だけ書いておきます。ホスト名・仮想マシン名・SSID・IP・MAC は出しません。
- ホスト: Windows 11 Pro / Hyper-V / 有線 LAN / 外部仮想スイッチ / Tailscale
- ゲスト: Windows / 固定 IP
- ネットワーク: 事業者変更直後、メッシュルーター新規認識
物理の回線は通っているのに、仮想マシンへの道だけが急に狭くなった感じでした。
最初に疑った候補
経験上、こういうときはだいたい次のどれかです。
- RDP サービスが止まっている
- Windows Defender Firewall が弾いている
- 固定 IP がズレた
- Hyper-V の外部スイッチが壊れた
- ネットワークプロファイルが Public のまま
全部あり得る。だから順番が大事です。
AI エージェント（今回は ChatGPT）にスクリーンショットと PowerShell の結果を渡しながら、仮説を立てては捨てる、を繰り返しました。
コンソールは生きている
まず Hyper-V マネージャからコンソール接続。
ログインできる。ゲストは起動している。ここが最初の安心材料でした。
RDP だけが落ちているなら、「VM が死んだ」線はかなり薄い。
Ping はタイムアウトした。でもそれだけじゃ断定できない
ホストからゲストへ Ping。
ping <ゲストIP>
タイムアウト。
ここで「ネットワーク断だ」と決めつけると、次の一手を誤りやすいです。Windows では ICMP だけ落とされていることが普通にあります。
なので、ゲスト側から見たネットワークをコンソール経由で確認しました。
ipconfig
固定 IP は想定どおり。
ping <ゲートウェイIP>
こちらは成功。
ゲスト自身の NIC と、ゲートウェイまでの道は生きていました。
3389 は LISTENING だった
次に、ゲストで RDP が待っているかを見ます。
netstat -an | find "3389"
LISTENING
出てきました。RDP サービス側は動いている。
ここまでで、「ゲスト OS が死んでいる」「RDP が止まっている」は外れです。
仮想スイッチはまだ作り直さない
ホスト側のアダプタも一応見ました。
Get-NetAdapter
外部スイッチは有線 NIC につながったまま。表示上は壊れていません。
ここで仮想スイッチを作り直すと、戻し作業が増える。症状がコンソール可・3389 待ち受けありなら、まだ早いと判断しました。
ネットワークプロファイルが Public だった
本命の確認です。
Get-NetConnectionProfile
Hyper-V 側の仮想 NIC が Public になっていました。
回線切替やルーター差し替えのあと、Windows が「知らないネットワーク」として扱うことがあります。家の中でも Public になると、RDP まわりが厳しくなります。
そこで、外部スイッチ側のプロファイルを Private に戻しました。
Set-NetConnectionProfile -InterfaceAlias "vEthernet (外部スイッチ)" -NetworkCategory Private
InterfaceAlias は環境ごとに違うので、必ず Get-NetConnectionProfile の結果からコピーしてください。記事中の名前はそのまま使わない前提です。
本当に 3389 へ届くか
プロファイル変更のあと、接続そのものを確認します。
Test-NetConnection <ゲストIP> -Port 3389
TcpTestSucceeded : True
これで次は揃いました。
- ゲストは起動している
- ゲストのネットワークは生きている
- 3389 は待っている
- ホストから TCP 3389 が通る
RDP クライアントを再度起動。今度は普通につながりました。
「いきなり直しに行かない」順番を図にすると、だいたいこうです。生きている層から上へ積んでいく。
今回学んだこと
- コンソールに入れるなら、まず「VM 死」は後回しでいい
- Ping 失敗だけでネットワーク断と決めない。ICMP は嘘をつく
- RDP なら 3389 の LISTENING と
Test-NetConnection -Port 3389をセットで見る - 回線・ルーター変更のあとは
Get-NetConnectionProfileを疑う - Public のまま直そうとして仮想スイッチを作り直すと、戻り作業が増える
「これだけが原因だった」と 1 行では言い切れません。事業者変更、メッシュ導入、仮想スイッチ、RDP、プロファイルが重なっていました。
ただ、PowerShell で事実を 1 個ずつ確認したあとなら、直す範囲を小さくできます。
AI エージェントと切り分けて感じたこと
いちばん効いたのは、答えを一発で貰うことではありませんでした。
スクリーンショットやコマンド結果を渡すたびに、
- 仮説を立てる
- 検証する
- 違えば捨てる
- 次の候補へ進む
というデバッグを隣で一緒に進めてもらえたことです。
一人だと「スイッチ作り直し」まで一気に飛びやすい。そこを、結果を見ながら止められたのが大きかったです。
AI エージェントは魔法の答え機というより、隣で一緒に切り分けてくれる相手として使うと噛み合います。
おわりに
回線を変えた直後にだけ、仮想環境の RDP が変な死に方をすることがあります。
0x204 を見たら、まずはプロファイルと 3389 の到達を疑う。作り直しは最後でいい、という順番を、これからも自分のチェックリストに残しておきます。
小さく。切り分けの順番だけは、忘れないようにします。
📎 図解版・関連リンクをまとめたページがあります:
https://ishizakahiroshi.com/articles/2026/2026-07-19_hyperv-rdp-0x204/
※ ヘッダー画像とインフォグラフィックは AI（画像生成）で作成しています。
※ 本文の挿絵も AI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。