WireGuardを設定する前に、端末の識別情報、接続先の識別情報、外側の接続先アドレスを区別し、トンネル内のAddressを確認しましょう。サービス提供元から設定情報を受け取っている方向けに、各項目を対応させて入力する手順を解説します。まずは既定のMTUで接続し、DNS、UDPの到達性、アイドル後の再接続を個別に確認することで、接続トラブルの原因を鍵やMTUだけに決めつけずに済みます。
鍵・トンネルアドレス・Endpointを区別する
ShadowrocketでWireGuardタイプを選んでも、それだけで接続できるわけではありません。WireGuardは鍵で通信相手を識別し、UDPでカプセル化したデータを送受信します。サーバー側にはクライアントのPublicKeyを登録し、割り当てたトンネルアドレスの使用を許可する必要があります。クライアント側の入力だけでは、サーバー側のピア設定を補えません。
この記事では、標準的なWireGuardの設定項目である[Interface]と[Peer]を使って各項目を説明します。これらは設定ファイル上の名称であり、Shadowrocketの編集画面でも同じグループ分けや表記になるとは限りません。入力時はアプリに表示される項目と照らし合わせてください。特に、Addressという表示だけでサーバーアドレスかトンネル内アドレスかを判断しないようにしましょう。
たとえば、192.0.2.10:51820はEndpointの「ホストアドレスとポート」の構造を、10.66.0.2/32はトンネル内IPv4アドレスの構造を示す例です。前者はドキュメント用の例示アドレスであり、どちらもこの記事が接続情報として提供するものではありません。実際の値は、すでにお持ちの設定情報で確認してください。ポート51820はよく使われる例で、すべてのWireGuardサービスで固定されているわけではありません。
PrivateKeyとPublicKeyの確認方法
PrivateKeyは現在のクライアントの秘密鍵です。対になるクライアントのPublicKeyをサーバー側に登録します。一方、クライアント側の[Peer]に設定するPublicKeyはサーバーの公開鍵です。この2つの向きを取り違えやすいため注意してください。自分の公開鍵を接続先の公開鍵欄に入力しても、形式が正しく見えるだけで、想定した認証はできません。
端末の識別情報とアドレス
- PrivateKey
- 現在のクライアント設定に記載された秘密鍵です。外部に漏らさないでください。
- クライアントのPublicKey
- 端末のPrivateKeyに対応する公開鍵です。サーバー側に登録します。
- Address
- サーバーから割り当てられたトンネル内アドレス。例：10.66.0.2/32
端末の秘密鍵、サーバーに登録されたクライアントの公開鍵、割り当てアドレスが対応している必要があります。
接続先の情報
- PublicKey
- 接続先サーバーの公開鍵です。クライアント自身の公開鍵ではありません。
- Endpoint
- サーバーのホスト名またはIPアドレスと、実際に使用するUDPポートです。
- PresharedKey
- 任意の事前共有鍵です。元の設定で指定されている場合にのみ入力します。
PresharedKeyの代わりにPrivateKeyやPublicKeyを使うことはできません。また、独自に値を追加しないでください。
WireGuardのBase64形式の鍵は、一般に末尾に=が付いた44文字です。これは入力時の形式確認の目安にすぎず、鍵が正しい接続先のものかどうかは判断できません。コピー時は余分な空白、改行、引用符がないか確認してください。文字数を合わせるために文字を追加・削除してはいけません。鍵が漏えいした場合は、該当する鍵を変更し、サーバー側の登録情報も更新してください。ノードの名前を変えるだけでは不十分です。
HomeでWireGuardを追加する手順
現在使えている設定は残したうえで、確認用の項目を新しく追加します。以下では手動入力を中心に説明します。既存のサブスクリプションから設定を取り込む場合は、WireGuardタイプとして登録されていることを確認してください。WireGuardの設定テキストを、サブスクリプションURL専用の入力欄に貼り付けないでください。また、どの形式の設定も同じインポート画面で認識されるとは限りません。
-
タイプを選択
Home → 右上の「+」→ Type → WireGuardの順に進みます。別のプロトコルの編集画面で同じ名前の項目を入力しないよう、先にタイプを確認してください。
-
接続先を入力
元の設定にあるEndpointのホスト名またはIPアドレスとポート番号を、それぞれサーバーアドレス欄とポート欄に入力します。たとえば192.0.2.10:51820なら、ホストは192.0.2.10、UDPポートは51820です。ここでは分け方だけを示しています。
-
鍵を対応させる
端末のPrivateKey、接続先のPublicKey、元の設定で指定されている場合はPresharedKeyを入力します。それぞれの入手元を確認し、クライアントとサーバーの公開鍵を取り違えないようにしてください。
-
アドレスを確認
割り当てられたトンネル内のAddressを、ローカルアドレスの項目に設定します。元の設定にIPv4とIPv6の両方がある場合は、それぞれ確認してください。画面上でアドレスとプレフィックスが別項目になっている場合は、表示に従って入力します。
-
保存して確認
保存後、Homeに戻って追加した項目を選び、Global Routingも確認します。初回接続時はシステムの案内に従ってVPN構成を許可してください。その後、接続スイッチの状態だけで判断せず、実際の通信で確認します。
サブスクリプション管理下の項目は、次回の更新時に元の設定で上書きされることがあります。MTUやPersistentKeepaliveを試す場合は、変更前の値を記録し、個別に保存できるテスト用の項目を使ってください。変更が消えた場合は、鍵を何度も入力し直す前に、サブスクリプションが更新されていないか確認しましょう。Shadowrocketでは、Home、Config、Settingsがそれぞれ接続先の選択、設定の管理、アプリの設定を担います。ノードを変更しても、現在選択中のConfigが自動で切り替わるわけではありません。
Address・AllowedIPs・ルールによる振り分けの違い
Addressはトンネルインターフェースのローカルアドレスです。DNSアドレスでも、サーバーのパブリックIPアドレスでもありません。/32はIPv4のホストアドレス1つ、/128はIPv6のホストアドレス1つを表します。サービス提供元から割り当てられたアドレスを、別の端末のアドレスに変更しないでください。同じ識別情報やアドレスを使い回すと、応答先が変わったり、接続が断続的になったりすることがあります。
| 項目 | 意味 | ここからは判断できないこと |
|---|---|---|
| Address | ローカルのトンネルアドレス。例：10.66.0.2/32 | パブリックサーバーアドレスとしては使えません |
| Endpoint | 外側のUDPデータを送信するホストとポート | ポートが開いていても、鍵の認証に成功したとは限りません |
| AllowedIPs | 標準WireGuardで接続先アドレスを選択し、受信元を制限する設定 | Shadowrocketのドメイン振り分けルールと同じものではありません |
| Global Routing | Shadowrocketで現在選択されている全体ルーティングの設定 | WireGuardの項目を選んでも、すべての通信がその項目を通るとは限りません |
標準的なWireGuardの設定では、0.0.0.0/0と::/0がそれぞれすべてのIPv4アドレスとIPv6アドレスを対象にします。ただし、WireGuardをShadowrocketのノードとして使う場合、実際の通信がそのノードを通るかどうかは、Global Routing、現在のConfig、適用されるポリシーも確認する必要があります。元の設定にこの2つの範囲が含まれているだけで、アプリ内のすべての通信がそのノードを使うと判断しないでください。
DOMAIN-SUFFIXはドメインの末尾で照合するルールです。WireGuardの鍵を検証するものではありません。IP-CIDRは宛先IPアドレスの範囲で照合するルールです。ローカルインターフェースにAddressを割り当てる設定ではありません。GEOIPはIPアドレスの地域情報を使って照合します。EndpointへのUDP通信が届かない問題を解決するものではありません。FINALは、先行するルールに一致しなかった場合に適用されるフォールバックルールです。適用されるポリシーが現在のWireGuardノードとは限りません。
MTU：まず基準値を保ち、大きなパケットの問題を確認する
MTUはトンネルインターフェースが扱えるIPパケットの最大サイズであり、通信速度の上限ではありません。WireGuardではカプセル化のため、外側のIP、UDP、プロトコルのオーバーヘッドが加わります。経路が収容できるパケットサイズを超え、Path MTU Discoveryも正常に機能しない場合、小さなリクエストは通る一方で大きな応答が止まることがあります。ハンドシェイクは正常なのにページの一部が読み込まれない場合、MTUを調べる手がかりにはなりますが、それだけで原因を断定することはできません。
既定値または元の設定を維持
推奨初回のテストでは、アプリの既定値、または元の設定で明示されたMTUを使い、鍵、アドレス、Endpointが正常に機能するかを確認します。この結果を以降の比較の基準にできます。
適したケース：初回設定、接続は正常、大きなパケットの問題は未確認
MTUだけを段階的に下げる
元の値が目標値より大きい場合に限り、1420から1380に下げるなど、小さな値で試し、同じリクエストを再度確認します。これらはトラブルシューティングの例であり、一般的な最適値ではありません。毎回MTUだけを変更し、元に戻せるよう変更内容を記録してください。
適したケース：小さなリクエストは通るが、大きな応答や特定のネットワークで繰り返し停止する
元の値に戻して再確認
MTUを下げても症状が変わらない場合は、元の値に戻し、UDPの到達性、DNS、サーバー側のルーティングを調べます。MTUを下げるとパケット数が増えることがあり、値を下げ続けてもすべての問題が解決するわけではありません。
適したケース：変更しても効果がない、または別の設定が原因と考えられる
IPv6を通すトンネルでは、インターフェースのMTUをむやみに1280未満にしないでください。1280はIPv6の最小リンクMTUに関わる重要な値です。調査中は同じWi-Fi、同じ宛先へのリクエストなど、ほかの条件をそろえ、変更前後の状態を記録しましょう。この記事の数値はテスト方法を説明するための例であり、特定の回線での実測値や性能を保証するものではありません。
DNSとPersistentKeepaliveの役割
DNSはドメイン名をIPアドレスに変換します。WireGuardの暗号化ハンドシェイクが成功しても、ドメイン名を解決できるとは限りません。Endpointにホスト名を使う場合、外側の接続を確立する前に、そのホスト名も解決する必要があります。「サーバーのホスト名を解決できない」場合と「トンネル接続後にアクセス先の名前を解決できない」場合を分けて考えてください。問い合わせ経路が異なる可能性があります。
標準的なWireGuard設定のDNSは、設定ツールが使う補助項目であり、WireGuardのハンドシェイク自体には含まれません。Shadowrocketのノードとして使う場合、元の設定にDNSの行があるだけで、アプリの名前解決が完全に切り替わるとは限りません。現在のConfigにあるDNS設定も確認してください。DNSサーバーにトンネル内からしかアクセスできない場合は、そこへ到達する正しい経路が先に必要です。
- ドメイン名で失敗し、既知のIPアドレスには到達できる：まずDNSサーバー、問い合わせ経路、IPv4/IPv6の応答を確認します。これは診断の手がかりであり、最終的な結論ではありません。
- Endpointにドメイン名を使っていて接続を開始できない：先に現在のネットワークでそのホスト名を解決できるか確認し、次にUDPポートを調べます。トンネル内のDNS設定を先に変更しないでください。
- アイドル状態のあと、最初のリクエストが停止する：鍵を再作成する前に、NATのマッピングが期限切れになっていないか確認し、PersistentKeepaliveの設定を検討します。
- ネットワーク切り替え後の復旧が遅い：Wi-Fiとモバイルネットワークの挙動を分けて記録し、特定のネットワークだけがEndpointのUDP通信を制限していないか確認します。
PersistentKeepaliveの単位は秒です。アイドル時にキープアライブパケットを送信し、NATやファイアウォールのマッピングを維持します。25秒はよく使われる目安ですが、必須の値ではありません。標準設定では0が周期的なキープアライブの無効を表します。間隔を短くすると、アイドル時の通信量が増えますが、接続が必ず安定するわけではありません。既存の設定とネットワークの状態を踏まえて決めてください。
パラメーターを同時に変えず、失敗する段階を切り分ける
Homeで接続がオンになっている場合、まず確認できるのはシステムのVPNトンネルが起動していることです。それだけではWireGuardの接続先が応答したとは限りません。遅延テストも、テスト方法を踏まえて判断してください。一度のタイムアウトだけでは、UDPが届かないのか、鍵が一致しないのか、テスト対象が応答しないのかを区別できません。接続確立、データ転送、名前解決、アイドル後の復旧のどの段階で失敗するかを特定しましょう。
| 確認できる現象 | 優先して確認する項目 | 次の対応 |
|---|---|---|
| 有効な応答がまったくない | Endpoint、UDPポート、双方の公開鍵の対応、PresharedKey | Wi-Fiとモバイルネットワークの両方でテストし、サーバー側の登録内容を確認する |
| 応答はあるが、宛先に到達できない | トンネルAddress、サーバー側の転送設定、現在選択中のノードとポリシー | リクエストが実際にそのノードを通っていることを確認し、次にサーバー側のルーティングを調べる |
| ドメイン名でのアクセスだけ失敗する | Endpointの名前解決とアクセス先の名前解決が行われる段階 | 同じルーティング条件で、名前解決の結果と既知のIPアドレスへの到達性を比べる |
| 小さな応答は届くが、大きな応答が止まる | 経路のMTU、IPv6の経路、中間ネットワークの制限 | MTUだけを変更し、同じテストを繰り返して結果を記録する |
| しばらくアイドル状態になると使えなくなる | NATマッピング、PersistentKeepalive、ネットワーク切り替え | アイドル時間を記録し、元の設定に沿ってキープアライブを調整して再テストする |
ルールによってテスト対象のノードが使われていない可能性がある場合は、Home → Global Routingで一時的にProxyを選択し、テスト対象のWireGuard項目が選ばれていることを確認します。これはルールによる振り分けの影響を減らすための操作であり、ノード自体を修復するものではありません。テスト後は元のConfigまたは通常の設定に戻し、診断用の設定をそのまま使わないようにしてください。
WireGuardのポートを443にすると接続しやすくなりますか？
接続先が該当するUDPポートを実際に待ち受けている場合に限り、変更できます。UDP 443とTCP 443は別の通信エンドポイントです。WebページがTCP 443で開けても、現在のネットワークから同じ宛先のUDP 443に接続できるとは限りません。ポートを推測して変更するのではなく、元の設定を確認してください。
同じWireGuard設定をiPhoneとiPadにそのままコピーできますか？
2台の端末で同じ識別情報とトンネルアドレスを共用できるとは限りません。接続先は直近に受信した有効なパケットに応じて通信エンドポイントを更新することがあり、設定の使い回しで端末同士が干渉する場合があります。各端末に対してサービス提供元が割り当てた識別情報とアドレスを使用してください。アプリの購入条件と、WireGuardの識別情報の割り当ては別の話です。
トラブルシューティング後は、鍵を含めずに変更記録を残しましょう。変更した項目、変更前後の値、使用したネットワーク、正常に戻ったリクエストを記録します。どのネットワークでも有効な応答がない場合は、Endpointと鍵の対応を再確認してください。特定のリクエストだけに問題がある場合は、DNS、ルールによる振り分け、MTUを調べます。複数の項目を同時に変更するより、この順序のほうが再現性のある結論を得やすくなります。