ShadowrocketのWireGuard設定方法｜PrivateKey・Peer・AllowedIPs・MTUを解説

1. InterfaceとPeerの役割を確認する

WireGuardの設定では通常、[Interface]で端末側のトンネルインターフェースを、[Peer]で通信を許可するリモート側を指定します。Shadowrocketの追加画面では各項目が個別に表示される場合があるため、設定ファイルの記載順に入力するのではなく、鍵を取り違えないようにしてください。

端末側のPrivateKeyが端末の識別情報となり、リモート側には対応する端末の公開鍵を登録します。端末側設定のPeerにあるPublicKeyは、リモート側の識別に使います。どちらもBase64形式の文字列であることが多く、長さや末尾の文字だけでは入力先を判断できません。

2. アドレス・鍵・ポートを項目ごとに確認する

Addressはトンネル内のアドレスで、リモートサーバーのアドレスではありません。たとえば10.66.0.2/32はIPv4のホストアドレスを示します。/32はプレフィックス長なので、任意に/24へ変更しないでください。画面でアドレスとプレフィックスが別項目になっている場合は、それぞれに分けて入力します。行全体をそのまま貼り付けないでください。

WireGuardの通信にはUDPを使用します。ポート51820は一般的な設定例であり、プロトコルで固定されたポートではありません。また、このポートを入力すれば必ず接続できるという意味でもありません。EndpointがIPv6の場合、設定ファイルでは通常[2001:db8::10]:51820の形式で記述します。画面でアドレスとポートが別項目の場合は、角括弧やコロンの扱いを入力欄の形式に合わせてください。

3. Homeで追加し、再現可能なテストを行う

作業前に元の設定を保存し、使用中のWi-Fiまたはモバイル通信と、現在のGlobal Routingの設定を記録してください。既存のサブスクリプションから設定を取り込んでいる場合は、WireGuardの項目が実際に含まれているか確認します。更新によって項目が作り直されることがあるため、手動で変更する前に差分を記録し、後から設定が保存されていないと誤解しないようにしましょう。

1. 元の設定情報を確認する

   端末側のPrivateKey、トンネルのAddress、リモート側のPublicKey、Endpointが揃っているか確認します。公開鍵だけ、またはポート番号だけしかない場合は、元の設定の提供元に確認してください。それだけで接続に必要な設定全体を導き出すことはできません。

2. プロトコルを選択する

   Home → + → Type → WireGuardの順に進みます。編集画面に表示される項目に合わせて、リモート側のアドレスとポート、端末側の鍵、トンネルのアドレスを入力します。画面によってはアドレスとプレフィックスが別項目になっています。設定ファイル全体を鍵の入力欄に貼り付けないでください。

3. リモート側の設定を確認する

   PeerのPublicKeyを入力し、手元の設定にPresharedKey、AllowedIPs、キープアライブ間隔が含まれているか確認します。該当する項目が画面にない場合、名前の似た別項目に入力せず、使用しているインポート方法がそのパラメータに対応しているか確認してください。

4. 保存して接続する

   保存後にHomeへ戻り、追加した項目を選んで接続スイッチをオンにします。初回接続時は、システムの案内に従ってVPN構成を許可してください。システムにVPNの状態が表示されても、トンネルインターフェースが起動したことを示すだけで、リモート側から応答があったとは限りません。

5. テスト結果を記録する

   Home → Global Routing → Proxyに一時的に切り替えて、選択した項目で対象へのリクエストを処理できるか確認します。テスト対象、症状、ネットワークの種類を記録してください。終了後は元のConfigまたは普段の設定に戻し、テスト用の設定をそのまま使い続けないようにします。

テスト中はSettings → On Demandに自動接続の条件が設定されていないか確認してください。On Demandはシステムが接続を開始する条件を管理するもので、ドメインごとのルール選択を決める機能ではありません。ネットワーク切り替え後に自動で再接続した場合は、そのことも記録し、WireGuardの設定変更による効果と混同しないようにしましょう。

4. AllowedIPsとGlobal Routingは別の階層で動作する

WireGuardのAllowedIPsは、IPアドレスの範囲とPeerを関連付けます。送信時は宛先に応じて通信を担うPeerを選び、受信時はそのPeerが使用できるトンネル内の送信元アドレスを制限します。ドメイン名は指定できず、ShadowrocketのDOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALとも異なります。

• 0.0.0.0/0はすべてのIPv4アドレスを表し、IPv6は含みません。
• ::/0はすべてのIPv6アドレスを表します。設定しても、リモート側に利用可能なIPv6の出口があるとは限りません。
• 10.66.0.0/24が対象とするのは指定されたプライベートネットワークの範囲で、インターネット上のすべての宛先ではありません。
• インポートや編集の際にAllowedIPsを変更できる場合は、元の設定の用途を維持してください。「すべてのWebサイトを開けるようにする」ために、むやみに対象ネットワークを広げないでください。

Shadowrocketでは、リクエストの最終的な経路としてWireGuardの項目が選択されているかも確認します。Configでは現在の設定にあるルールとポリシーに従って処理されます。ルールに一致しない通信が必ず直接接続になるとは限らず、最終的な動作はフォールバック設定によって異なります。AllowedIPsが広い範囲をカバーしていても、DIRECTに一致するリクエストが自動的に選択中のWireGuard経路へ切り替わるわけではありません。

5. 接続後も問題が続く場合のDNS・MTU確認

DNSは名前解決の方法を決める

WireGuardのハンドシェイクは設定ファイルのDNS項目に依存しません。ただし、Endpointをドメイン名で指定している場合、外側の接続を確立する前に名前解決が必要です。トンネル接続後もWebサイトのドメイン名を解決する必要があります。「Endpointの名前解決失敗」と「Webサイトのドメイン名の名前解決失敗」は分けて記録し、どちらも鍵のエラーとして扱わないでください。

設定ファイルのDNSは、通常、クライアントの設定ツールが追加する項目であり、WireGuardプロトコル自体が交換するパラメータではありません。インポート後はConfigを開き、現在有効な設定のDNS項目と、DNSリクエストが実際に通る経路を確認します。元のファイルにあるDNS設定がShadowrocketの既存設定を必ず上書きするとは限りません。

• DNSアドレスがトンネル内のプライベートアドレスの場合は、まずトンネル経路とリモート側へのアクセス権限が有効か確認してください。接続が確立する前からそのDNSを使うと、接続が成立しない原因になることがあります。
• 特定のドメインだけ解決できない場合は、タイムアウト、応答なし、誤ったアドレスなど、症状を具体的に記録してからDNS設定と適用ルールを確認します。
• 「IPアドレスに直接アクセスできた」だけで判断しないでください。HTTPSではドメイン名、証明書、SNIも関係するため、IPアドレスで開いたページとドメイン名で開いたページが同じサービスとは限りません。

MTUはトンネル内のパケットサイズ上限を決める

MTUが大きすぎる場合、接続したように見え、短いテキストは取得できても、大きなページやファイルのアップロード、データ転送が止まることがあります。これは判断材料の一つであり、確定診断ではありません。リモート側の混雑、UDPパケットの損失、サーバー側の制限でも似た症状が起きます。MTUが小さすぎるとパケット数やカプセル化のオーバーヘッドが増える場合があり、小さくすれば安定するとは限りません。

1. まず設定の提供元が指定したMTUを維持し、同じネットワーク、同じ宛先、同じ操作での結果を記録します。
2. 元の値が1420なら、比較テストとして1380を試す方法があります。これらはテスト用の例で、すべてのネットワークに最適な値ではありません。
3. 保存後に接続を切り、再接続してから同じテストを繰り返します。このときDNS、Endpoint、鍵は同時に変更しないでください。
4. 改善しない場合は元の値に戻し、経路上のパケット損失やリモート側の状態を確認します。IPv6トンネルでは、最小リンクMTUの1280を下回る値にむやみに下げないでください。

6. 症状から原因を切り分け、1回の遅延テストだけで判断しない

遅延テストの結果は、特定の方法で測定した値であり、実際の通信が使えることを保証しません。外側のUDP通信、Peerの識別情報、トンネルアドレスとリモート側のルート、DNS、アプリのリクエストの順に確認します。リモート側のハンドシェイクや送受信カウンターを確認できる場合は、実際にリクエストを送信した時刻と照らし合わせてください。画面に接続アイコンが表示されたかだけで判断しないようにします。

7. トラブルの記録と利用上の注意

有効なトラブル記録には、接続情報を漏らさず、同じ条件で問題を再現できる情報が必要です。関係のない設定を次々と変更するより、使える元の設定を保存しておく方が役立ちます。確認後は普段のGlobal Routing設定に戻し、On Demandが想定どおりか確認してください。

• 環境：iPhoneまたはiPad、Wi-Fiまたはモバイル通信、テスト対象、失敗する具体的な操作を記録します。
• 経路：選択した項目、Global Routingの設定、Configで一致したルールまたはポリシーを記録します。
• 変更点：「MTUを1420から1380に変更」のように一度に一項目だけ記録し、PrivateKeyやPresharedKeyは公開しないでください。
• 結果：名前解決の失敗、接続タイムアウト、一部ページの異常、大容量データ転送の停止を区別し、元の値に戻した後の状態も記録します。