「先週までは普通につながっていたリモートデスクトップが、急に“エラーコード: 0x4（拡張 0x0）”で落ちるようになった」。しかも VPN や VMware コンソールからは入れるのに、Microsoft Remote Desktop からだけ失敗する——そんな現場トラブルを、Windows Server 2003 など古いサーバー／IPv6／DHCP 切替の観点から体系的に整理し、再現例ベースで原因と対処法をまとめます。
リモートデスクトップ「エラーコード: 0x4」とは何か
Microsoft Remote Desktop（以下 MRD）で接続に失敗したとき、macOS 版では「接続に失敗しました（エラーコード: 0x4（拡張 0x0））」のようなエラーが出ることがあります。0x4 自体は「接続が切断された」というかなり汎用的なコードで、次のような複数の要因で発生し得ます。
- サーバー側とクライアント側の暗号化方式・プロトコルが合わずハンドシェイクで失敗
- 途中のネットワーク経路（特に IPv6 や MTU、ルーティング）の不整合
- DHCP や DNS、ファイアウォールなどの設定差による経路不良
- RDP の UDP/TCP ネゴシエーションでの失敗
つまり「0x4 が出た＝この原因」とは断定できず、どのパターンに当てはまるかを切り分けることが重要です。本記事では、実際の報告例が多い次の 3 つのパターンに絞って解説します。
- 古い Windows Server 2003 系と MRD のアップデートの相性問題
- iPhone テザリング経由でのみ発生する、IPv6 経路起因の 0x4
- DHCP サーバーを Mikrotik などに切り替えた後にだけ発生する 0x4
よくある症状パターンと前提環境
まず、実際の現場で共有された共通点を整理しておきます。
- 先週までは正常に接続できたリモート PC（主に仮想環境上の Windows Server 2003 R2）へ、ある日を境に RDP だけ接続不能になった。
- VPN 接続や VMware／Hyper-V コンソール経由では問題なくログオンできる。
- macOS 版 Microsoft Remote Desktop（例: 10.8.2）からだけ接続に失敗し、エラーコード: 0x4（拡張 0x0）。
- 同じ MRD からでも、Windows 10 など新しめの VM には問題なく接続できる場合がある。
- 2023 年春以降、似たような事例が複数の環境でほぼ同時期に発生。
- その後のヒアリングで、iPhone テザリング経由（IPv6 優先）でのみ 0x4 が出るケース、DHCP を Mikrotik に切り替えた直後から 0x4 が出始めたケースも報告された。
ここから分かるのは、0x4 は「サーバー OS の世代」「クライアント（MRD）のバージョン」「ネットワーク（IPv4/IPv6・DHCP）」という 3 つの軸のどれでも発生し得るということです。
原因パターン1：古い Windows Server 2003 × MRD のアップデート
なぜ 2003 系だけ突然つながらなくなるのか
Windows Server 2003 / 2003 R2 時代の RDP は、現在の標準から見るとセキュリティ機能がかなり限定的です。代表的な違いを表にまとめると次のようになります。
| 項目 | Windows Server 2003 系 | Windows Server 2012 以降 |
|---|---|---|
| NLA（ネットワーク レベル認証） | 非対応 | 標準対応 |
| TLS バージョン | 主に TLS 1.0（古い暗号スイート） | TLS 1.2 以降が利用可能 |
| 暗号スイート | RC4 等の現在では非推奨な方式を含む | より強度の高い暗号スイートに対応 |
| セキュリティ層 | RDP セキュリティが主流 | SSL（TLS）セキュリティが主流 |
一方で、macOS の MRD クライアントは、バージョンアップの際に「古く危険な暗号スイート」や「脆弱なプロトコルバージョン」を順次無効化していきます。その結果、
- Windows Server 2019 など新しいサーバーとは安全な方式で握手できる
- Windows Server 2003 とは「使える共通方式がない」状態になり、ハンドシェイクでエラー
- MRD 側には「エラーコード: 0x4」として現れる
という事態が起きます。実際に、MRD の直近アップデート以降、2003 系だけつながらなくなったという報告は少なくありません。
MRD のバージョン差異による再現性確認
切り分けとして有効なのが、次のようなパターンです。
| クライアント | サーバー OS | 結果 | 想定される状況 |
|---|---|---|---|
| MRD 10.8.2（最新寄り） | Windows Server 2003 R2 | 0x4 で失敗 | TLS/暗号スイートのミスマッチ |
| MRD 10.5.2（旧版） | Windows Server 2003 R2 | 接続成功 | 旧 MRD はまだ古い方式を許容している |
| MRD 10.8.2 | Windows Server 2019 | 接続成功 | サーバー側が新しい TLS/暗号に対応 |
このように、「新しい MRD × 古い 2003 系サーバー」の組み合わせにだけ 0x4 が集中しているなら、クライアントのセキュリティ強化がトリガーになっている可能性が非常に高くなります。
対処方法（暫定策／現実的な落とし所）
2003 系サーバーにどうしても接続する必要がある場合、現実的な対処方法は次の 3 つです。
- MRD を旧バージョンへロールバックする
- Mac App Store からは旧版を直接入手しにくいこともありますが、Time Machine で戻す、旧 Mac からコピーするなどの方法で 10.5.2 などの旧 MRD を利用したところ、接続が復旧した例があります。
- ただし、古いクライアントを使い続けることはセキュリティリスクでもあるため、「2003 への接続専用 Mac」として用途を限定するのが現実的です。
- 別の RDP クライアントを利用する
- Windows PC 側で
mstsc.exe（標準のリモートデスクトップ接続クライアント）を利用する。 - 他社製 RDP クライアント（古い暗号にも対応しているもの）を利用する。
- Windows PC 側で
- サーバー側の RDP セキュリティレベルを下げる（2003 限定）
- ターミナル サービスの設定で、「暗号レベル：クライアント互換」「セキュリティ層：RDP セキュリティ」に変更すると、接続できるようになる場合があります。
- ただし、これは セキュリティをさらに弱くする措置であり、インターネット越しの公開には絶対に使用すべきではありません。
いずれの場合も、最終的なゴールは OS の更新（Windows Server 2019/2022 など）であり、2003 系は段階的に退役させていくことを強くおすすめします。
原因パターン2：iPhone テザリング経由でのみ 0x4（IPv6 起因）
モバイル回線特有の「IPv6 優先」が落とし穴に
別の報告では、「社内ネットワーク経由では問題ないのに、iPhone のテザリングで接続したときだけ MRD が 0x4 を返す」という現象が共有されています。このときの主なポイントは次のとおりです。
- 一部の携帯キャリアや iPhone は、テザリング時に IPv6 を優先する構成になっている。
- クライアント（Mac）が IPv6 経由でサーバーへ到達しようとするが、VPN やルータ側が IPv6 の経路をきちんと扱っておらず、途中でパケットが破棄される。
- その結果、TLS ハンドシェイクや RDP のネゴシエーションが正常終了せず、0x4 が発生する。
また、IPv6 と IPv4 のデュアルスタック環境では MTU 周りの不整合も起きやすく、RDP のように長めのパケットを継続送受信するプロトコルでは、途中でセッションが途切れたような挙動につながることがあります。
IPv6 起因の 0x4 への対処
このパターンでは、「とにかく IPv6 を回避して IPv4 だけで試す」のが手っ取り早い切り分けになります。
- キャリア側に相談し、IPv4 専用の APN やプロファイルを発行してもらう。
- iPhone 側のモバイルデータ設定で、IPv6 を使用しない構成（可能な範囲で）に変更する。
- Mac 側のネットワーク設定で、そのテザリングインターフェースに限り IPv6 を無効化してみる。
- 一時的な回避策として、別の回線（固定回線＋Wi-Fi や別キャリア回線）で試す。
これらのいずれかで 0x4 が解消する場合、原因はほぼ IPv6 周りに絞り込めます。根本的には、VPN やファイアウォール側で「IPv6 トラフィックをどう扱うか」を明示的に設計することが重要です。
原因パターン3：DHCP を Mikrotik に切り替えた後のみ 0x4
DHCP オプションの不整合と RDP
もう一つ、多くの管理者が見落としやすいのが「DHCP サーバー切替後にだけ発生する 0x4」です。Windows DHCP から Mikrotik 等に切り替えたところ、
- 静的 IP 設定の端末からは RDP 接続できる
- 新しい DHCP サーバーからアドレスを取得した端末だけ 0x4 になる
という挙動が見られるケースがあります。この場合、疑うべきは次のような DHCP オプションです。
| DHCP 項目 | 問題になりやすい例 | RDP への影響 |
|---|---|---|
| デフォルトゲートウェイ | サブネットに合わない GW を配布 | 外部ネットワークに出られず、RDP が途中でタイムアウト |
| DNS サーバー | AD DNS ではない外部 DNS を配布 | ドメイン参加端末のネットワークプロファイルが変わり、GPO や FW が変化 |
| オプション 121/249 （クラスレス静的ルート） | 誤ったスタティックルートを全端末に配布 | RDP の経路が誤ルートに吸い込まれ、途中でドロップ |
| MTU 関連（ベンダー独自） | 不適切な MTU 値を配布 | 大きめの RDP パケットが断続的に破棄される |
DNS 切替とドメインプロファイルの変化
特にドメイン環境では、DHCP で配布する DNS を AD の DNS から外部パブリック DNS に変えてしまうと、クライアントがドメインコントローラーへ正しく名前解決できず、結果として
- ネットワークの種類が「ドメイン」から「プライベート」「パブリック」に変わる
- ドメイン向けに設計していた GPO（RDP 許可やファイアウォール例外）が効かなくなる
- 最終的に、RDP 3389 がブロックされる
といった副作用につながります。VPN 越しにドメインサーバーへ接続している場合などは、なおさら注意が必要です。
Mikrotik やルータ固有機能による影響
Mikrotik など高機能ルータでは、次のような機能が RDP セッションに影響を与えることがあります。
- FastTrack による接続追跡の省略が、一部トラフィックの戻りを不安定にする。
- NAT（特にマルチセッション環境）で 3389/UDP のセッション管理がうまくいかず、RDP の UDP ネゴシエーションだけ失敗する。
- 一部のフィルタリング設定で「関連／確立済み」トラフィックの扱いが不完全になっている。
こうした影響を切り分けるため、まずは Mikrotik 側で次のような対応を行うとよいでしょう。
- 対象クライアントとサーバー間のトラフィックについて、一時的に FastTrack を無効化する。
- RDP 用の NAT/FW ルールを簡素化し、TCP/UDP 3389 の双方を明示的に許可する。
- 可能であれば、検証用に「すべて許可」のバイパスセグメントを作り、そこで再現が起こるか確認する。
迅速な切り分けフロー
ここまでの内容を踏まえ、実際のトラブルシューティングで使えるおすすめの実行順を整理します。
1. 対象サーバー OS の世代を確認する
- Windows Server 2003 / 2003 R2 の場合：まず MRD を旧版にして試す。
- 2008 R2 以降であれば、NLA や TLS 設定、RDP 暗号レベルを確認していく。
2. ポート疎通を確認する（ping ではなく 3389）
ping（ICMP）は通っても、RDP ポート（TCP/UDP 3389）が閉じているケースはよくあります。必ずポートレベルでテストしましょう。
macOS から：
nc -vz <サーバーIP> 3389
# または
telnet <サーバーIP> 3389
Windows から（PowerShell）：
Test-NetConnection -ComputerName <サーバーIP> -Port 3389
ここで TCP 3389 に到達できない場合、0x4 以前の問題として「経路やファイアウォール」が疑われます。
3. RDP の UDP を無効化してテストする
RDP は既定で UDP も併用しますが、UDP 側が途中でブロックされると、セッションが不安定になったり 0x4 が出たりすることがあります。サーバー側 GPO で一時的に TCP のみに固定して挙動を確認します。
- グループポリシーの該当設定：
「リモート デスクトップ サービス > リモート デスクトップ セッション ホスト > 接続 > RDP のトランスポート プロトコルを選択」 - これを「TCP のみ」に設定してクライアントから再接続。
これで安定する場合、UDP 経路（ルータ／ファイアウォール／NAT）の問題と考えられます。
4. DHCP 経由と静的 IP で挙動が変わるか確認する
同じクライアント PC でも、
- DHCP でアドレスを取得した状態：RDP が 0x4 で失敗
- 手動で静的 IP／DNS／GW を設定した状態：RDP が成功
という差が出る場合、原因はほぼ DHCP オプションの配布内容です。具体的には次を比較します。
- IP アドレス／サブネットマスク
- デフォルトゲートウェイ
- DNS サーバー／DNS サフィックス（ドメイン名）
- WINS サーバー（古い環境）
- オプション 121/249（クラスレス静的ルート）
- ベンダー固有の MTU 設定
DHCP で配っている値を静的設定と完全に一致させても 0x4 が出るかどうかを確認すると、問題の切り分けがしやすくなります。
5. テザリング・モバイル経由なら IPv4 のみにして再試行
iPhone テザリングなどモバイル回線経由でのみ 0x4 が出る場合は、
- APN 設定やプロファイルを IPv4 専用にする
- Mac 側で該当インターフェースの IPv6 を無効化する
- 別キャリア・別回線を使って接続テストする
という形で IPv6 を排除した状態を作り、症状が消えるかを確認します。
6. サーバー側イベントログを確認する
Windows サーバー側のイベントログ（ターミナル サービス／RDS 関連）には、クライアント側では見えないヒントが出ていることがあります。
- TLS ハンドシェイクに失敗したログ
- 暗号スイートが交渉できなかったことを示すメッセージ
- ライセンス関連、同時接続数関連のエラー
特に 2003 系では情報量こそ少ないものの、「そもそも接続要求が届いていないのか」「握手途中で落ちているのか」の切り分けに役立ちます。
7. 代替クライアントで再現性を確認する
最後に、クライアント依存の問題を洗い出すため、次のような比較を行います。
- macOS の MRD と、Windows の
mstscで同じサーバーに接続してみる。 - macOS 上で他社製の RDP クライアントを利用してみる。
MRD だけで 0x4 が発生し、他のクライアントでは問題ない場合、MRD 固有の暗号スイート制限やバグの可能性が高まります。この場合は、バージョン変更（アップデート／ダウングレード）や設定見直しが有効です。
運用上の注意点：2003 系サーバーは「つなげる」より「脱出計画」を
ここまでの対処法はあくまで「現場で今困っている」状況を救うための暫定措置です。特に Windows Server 2003 は既にサポートが終了しており、
- 新規の脆弱性に対する公式パッチが提供されない
- 新しいクライアントや OS が古い暗号をどんどん排除していくため、時間が経てば経つほど相性問題が増える
- コンプライアンス（セキュリティ基準）への適合が難しくなる
といった構造的な問題を抱えています。
そのため、
- 2003 系サーバーは「閉域網＋限定ユーザー＋限定用途」に絞り、外部公開を避ける。
- アプリケーションの依存関係を洗い出し、順次 2019/2022 など新しい OS への移行計画を立てる。
- どうしても移行できないアプリは、仮想マシンとして隔離し、管理用経路も分離する。
といった中長期的な方針を検討することをおすすめします。「つながるようにする」だけでなく、「安全につながらなくする（退役させる）」方向の設計も重要です。
よくある質問と追加 Tips
Q. 0x4 は必ず暗号化の問題ですか？
A. いいえ。0x4 はあくまで「接続が切断された」という汎用的なエラーコードであり、
- TLS／暗号スイートの不一致
- IPv6 の経路不良や MTU 問題
- DHCP／DNS／ルーティングの誤設定
- UDP 3389 の片方向ブロック
など、さまざまな要因で発生します。この記事で紹介した 3 パターン（2003＋MRD、IPv6、DHCP 切替）を順に疑うのが現実的です。
Q. ping が通っていればネットワークは問題ないと考えていいですか？
A. いいえ。ping は ICMP を使うため、TCP/UDP 3389 が開いているかどうかとは別問題です。必ず前述した Test-NetConnection や nc / telnet などで ポートレベルの疎通を確認してください。
Q. Mikrotik や他のルータで MTU が原因かどうかを簡単に確認する方法は？
A. すべてを正確に見るにはパケットキャプチャが必要ですが、簡易的には次のような方法があります。
- VPN トンネルや WAN インターフェースの MTU を 1400 など小さめに設定し、フラグメントを避ける。
- クライアント PC 側のインターフェース MTU を試験的に下げてみる。
- HTTP など別プロトコルで大容量データのダウンロード／アップロードを行い、途中で切断されないか確認する。
これらを行って RDP が安定するなら、MTU 関連の問題が強く疑われます。
Q. MRD のバージョンを固定して運用してもよいですか？
A. 短期的には「2003 系サーバー接続専用クライアント」として MRD の旧版を使うのは現実解です。ただし、
- インターネット閲覧やメールなど他の用途と兼用しない（分離運用する）。
- 可能な限り閉域網に接続した端末でのみ利用する。
- アップデートを止めている端末であることを管理台帳などに明記する。
など、セキュリティリスクを把握したうえでの限定運用が必須です。
Q. DHCP を Mikrotik へ切り替える際の事前チェックポイントは？
DHCP 切替に伴うトラブルを避けるため、次のようなチェックリストを用意しておくと安心です。
| チェック項目 | ポイント |
|---|---|
| サブネット／GW 設定 | 旧 DHCP と完全一致するか（VLAN やルーティングも含めて） |
| DNS サーバー | ドメイン環境なら AD DNS を最優先で配布しているか |
| オプション 121/249 | 不要なルートを追加していないか、誤ネットワークを指定していないか |
| MTU 関連 | ベンダー固有オプションで異常な値を配布していないか |
| 検証用セグメント | DHCP 切替前に、テスト用 VLAN で RDP／ファイル共有などを検証したか |
まとめ：0x4 は「総称」だからこそパターンで攻める
リモートデスクトップの「エラーコード: 0x4（拡張 0x0）」は、原因が 1 つに決まっているわけではなく、
- 古い Windows Server 2003 系と新しい MRD の相性問題
- モバイル回線や iPhone テザリングでの IPv6／MTU／経路不良
- DHCP サーバー切替後の DNS／ルート／MTU の不整合
など、複数の要因が「同じエラーコード」として表面化している状態です。そのため、やみくもに設定を変えるのではなく、
- サーバー OS の世代を見て、2003 系なら MRD 旧版やセキュリティ層の調整を試す。
- ポート疎通・UDP 無効化・代替クライアントで「ネットワークか暗号か」を切り分ける。
- テザリングや DHCP 切替の有無を確認し、IPv6 と DHCP オプション（特に 121/249 や DNS）を重点チェックする。
というパターンベースの切り分けが非常に有効です。
そして、もし原因が「Windows Server 2003 と最新クライアントの相性」だと判明した場合、短期的な回避策はありつつも、最終的な解決策はサーバー OS の更改に他なりません。0x4 のトラブルシューティングをきっかけに、自社のサーバー更新計画やネットワーク設計を見直す良い機会と捉えてみてください。
コメント