この記事は、利用中のサービスから取得したWireGuard設定情報をお持ちの方を対象にしています。まずローカルのInterfaceとリモートのPeerを区別し、Add Serverの入力手順に沿ってアドレス、ポート、鍵、トンネル関連の項目を確認します。最後にAllowedIPs、Global Routing、MTUを個別にチェックします。各値をどちら側に入力するか、「接続スイッチはオンなのに通信できない」場合にどの段階を調べるかが分かります。
1. InterfaceとPeerを見分ける
ShadowrocketのWireGuardタイプでは、WireGuardプロトコルを使ってトンネルを確立します。通信にはUDPを使用し、双方の識別には鍵を使います。ユーザー名とパスワードを入力して接続する方式ではありません。この記事では、利用者が正規に取得した設定情報を使うことを前提とします。各項目には、現在の端末用に割り当てられた同一の設定情報を使用し、別の端末やPeerの値を混在させないでください。
一般的な設定ファイルは[Interface]と[Peer]の2つのセクションに分かれています。前者はローカルのトンネルインターフェース、後者はリモート側の情報を示します。Home → 右上の「+」→ Add Server → Type → WireGuardと進んだら、設定ファイルの行を上から順にコピーするのではなく、各項目の意味に合わせて入力してください。フォームのグループ分けや任意項目の位置は、画面の更新により変わることがあります。
| 設定の区分 | 主な項目 | 入力前の確認 |
|---|---|---|
[Interface] | PrivateKey、Address、MTU | 現在のクライアントを示す項目です。サーバーの秘密鍵や公開アドレスではありません。 |
[Peer] | PublicKey、Endpoint、AllowedIPs | リモート側の識別情報、接続先、Peerに許可するアドレス範囲を示します。 |
[Peer]の任意項目 | PresharedKey、PersistentKeepalive | 元の設定に記載がある場合、またはネットワーク上必要な場合のみ入力します。 |
| 名前解決の設定 | DNS | 名前解決に関する設定です。Peerの公開鍵やEndpointのポートではありません。 |
2. Add Serverでアドレスと鍵を入力する
追加時は、まずリモートのアドレスとポートを確認し、次に両側の鍵を照合してから、ローカルアドレスと詳細項目を確認します。以下は入力の流れに沿った手順です。WireGuard専用項目が別のグループに表示される場合も、項目の意味に合わせて入力してください。
-
タイプを選択する
Home →「+」→ Add Server → Type → WireGuardの順に進みます。先にTypeを確認してから設定を入力し、別のプロトコルのフォームで同名の項目を探さないようにします。
-
Endpointを分ける
元の設定にあるEndpointを、Addressのリモートホスト名とPortのポート番号に分けます。たとえば
vpn.example.com:51820は形式の説明用です。ホスト名はvpn.example.com、ポート番号は51820です。実際にはご自身の設定値を入力してください。 -
鍵を照合する
PrivateKeyにはローカルのInterface秘密鍵を、PublicKeyにはリモートPeerの公開鍵を入力します。元の設定にPresharedKeyがある場合は、対応する項目にも入力してください。クライアント自身の公開鍵をリモート側の公開鍵として入力しないでください。
-
トンネル項目を入力する
InterfaceのAddressをローカルのトンネルアドレス欄に入力します。フォームで対応している形式に合わせて、アドレスの種類とプレフィックスを維持し、AllowedIPs、MTU、必要に応じてPersistentKeepaliveも確認してください。
-
保存して確認する
保存後にHomeへ戻り、追加した設定を選択してGlobal Routingを確認します。初回接続時は、システムの案内に従ってVPN構成を許可してください。その後、選択した設定を通ることが明確な通信でテストします。
Addressは項目の文脈によって意味が異なります。Add Serverの共通アドレス欄は通常リモートサーバーを指しますが、WireGuardのInterfaceにあるAddressはローカルのトンネルアドレスです。例:10.66.0.2/32。転記時は項目が属するグループを確認し、プライベートネットワークのトンネルアドレスをリモートサーバー欄に入力しないでください。IPv6のEndpointは、元の設定では[2001:db8::10]:51820のように記載されることがあります。角括弧はアドレスとポートを区切るためのもので、ローカルインターフェースのアドレスを示すものではありません。
PrivateKey、PublicKey、PresharedKeyはいずれもエンコードされた鍵の値で、通常のパスワードでは代用できません。WireGuardの鍵は32バイトで、一般的なBase64表記は44文字です。文字数が一致すれば欠落の発見には役立ちますが、鍵の組み合わせが正しいとは限りません。コピー時は末尾の=、見えない改行、前後の空白に注意してください。
3. AllowedIPsとGlobal Routingの役割
AllowedIPsは、WireGuardのPeerに設定するアドレスプレフィックスの集合です。送信時には宛先アドレスをどのPeerに渡すかの判定に使われ、受信時にはそのPeerから利用できる送信元アドレスも制限します。Webサイトのドメイン一覧ではないため、example.comやDOMAIN-SUFFIXルールをそのまま入力することはできません。
Shadowrocketのルール層とWireGuardのPeer層では、別々の判定が行われます。Global RoutingでProxy、Direct、Config、Sceneなどを選ぶと、リクエストをどのようにポリシー処理へ渡すかが決まります。リクエストがWireGuardに渡された後も、Peerのアドレス範囲やリモート側の転送条件を満たす必要があります。AllowedIPsを変更しただけで、アプリのすべての通信がそのトンネルを通るとは限りません。
| 設定 | 意味 | 適用範囲 |
|---|---|---|
0.0.0.0/0 | IPv4の全アドレス範囲を対象にします。 | IPv6は対象外です。また、Global Routingの選択に代わるものではありません。 |
::/0 | IPv6の全アドレス範囲を対象にします。 | リモート側とローカル側の設定が、IPv6に対応している必要があります。 |
10.20.0.0/16 | 指定したIPv4ネットワークだけを対象にします。 | 対象が限定されたネットワークの場合、そのPeer経由ですべてのインターネット上の宛先に接続できるとは限りません。 |
DOMAIN-SUFFIX、IP-CIDR、FINAL | Configで使うルールキーワードです。 | リクエストに適用するポリシーを制御します。ルール設定に記述し、AllowedIPsには入力しません。 |
要点:2つの範囲を分けて確認する
インターネット上の宛先に接続できない場合は、まず対象のリクエストが実際にWireGuardを選択しているか確認し、次にAllowedIPsに宛先のアドレス種別とネットワークが含まれているかを調べます。片方だけが正しくても、通信経路が使えるとは限りません。
Configの場合は、現在有効な設定のルール順と、最終的に適用されたポリシーを確認します。DirectはWireGuardの出口確認には適しません。Sceneは、現在のシーンの設定に応じて判断してください。ルールの影響だけを切り分ける場合は、元の設定を記録してから一時的にProxyを使い、テスト対象のWireGuardを選択します。確認が終わったら、元の設定に戻してください。
4. MTU、UDPポート、Keepaliveの設定範囲
MTUは、トンネルインターフェースから送信できるIPパケットの最大サイズをバイト単位で制限します。トンネルのカプセル化には外側のパケット領域が必要なため、接続ネットワークのMTUをそのままトンネルで使える値と見なすことはできません。MTUが大きすぎると、小さなリクエストは通る一方で、大きな応答が止まることがあります。ただし、DNS、リモート側の転送、ネットワークのパケット損失でも似た症状が起こるため、Webページが開かないことだけを根拠に結論を出さないでください。
- MTU:まずは、現在の経路向けにサービス提供元が指定した値を使ってください。外側の経路MTUが1500の場合、WireGuardのオーバーヘッドは外側がIPv4なら約60バイト、IPv6なら約80バイトとして見積もられることが多く、1420はよく使われる初期値です。ただし、すべてのネットワークに適用できる値ではありません。
- Port:Endpointと一致させる必要があります。サーバーが別のUDPポートを使っているなら、例に51820とあっても51820に変更しないでください。WebページやTCPのテストに成功しても、同じアドレスのUDP通信が正常とは限りません。
- PersistentKeepalive:一定間隔でKeepaliveデータを送信し、NATマッピングの維持を助けます。元の設定が25なら通常は25秒を意味し、25ミリ秒ではありません。0は通常、定期的なKeepaliveを無効にします。
- PresharedKey:双方で追加共有する鍵で、両端の値を一致させる必要があります。元の設定にない場合は、クライアント側だけで独自に生成して入力しないでください。不一致の原因になります。
要点:変更する値は一度に1つだけ
Handshakeとルーティングを確認した後、大きな応答だけに問題がある場合は、元のMTUを記録したうえで、1420から1380に一時的に下げて比較します。改善しなければ元の値に戻し、経路の確認を続けてください。これは原因を切り分けるための手順であり、速度向上を保証するものではありません。
5. 接続許可からWebアクセスまでの確認手順
Homeの接続スイッチがオンでも、クライアントが通信処理を開始したことを示すだけで、WireGuardのHandshake完了やDNS、リモート側の転送が正常であることを意味しません。WireGuardは通常、必要に応じてHandshakeを行います。確認時は、その設定に実際に渡されるリクエストを発生させ、表示可能なログや統計情報、サービス提供元の状態と照らし合わせてください。
- 許可と選択中の設定を確認:システムのVPN構成が許可されていること、Homeで対象のWireGuardが選択されていることを確認します。別の保存済み設定が選ばれていないかも確認してください。
- リクエストの経路を確認:Global Routingを確認します。Configの場合は、対象のリクエストが想定したポリシーに適用されているか調べてください。切り分け中はSettings → On Demandの状態も記録し、自動接続ルールが手動での切断・再接続の確認に影響しないようにします。
- Endpointへの到達性を確認:リモート側にドメイン名を使っている場合は、まず名前解決できるかを確認し、次に現在のネットワークで指定したUDPポートが許可されているかを調べます。Wi-Fiとモバイル通信を切り替えると、接続ネットワークの影響を切り分けやすくなります。テスト中は同じ設定を使用してください。
- 鍵の組み合わせを確認:ローカルのPrivateKeyが、サーバーに登録されたクライアント公開鍵に対応しているか、リモートのPublicKeyが現在のPeerのものかを確認します。設定が正しそうでもHandshakeが成立しない場合は、元の設定を提供したサービスに登録内容の確認を依頼してください。
- データ通信と名前解決を確認:Handshakeが成立しているのに応答がない場合は、AllowedIPs、リモート側の転送設定、アクセス権を確認します。ドメイン名でのアクセスだけに問題がある場合はDNSの経路を調べ、MTUや鍵を先に変更しないようにしてください。
6. WireGuard設定を転記する際によくある質問
PrivateKeyとPublicKeyを入れ替えて試してもよいですか?
できません。元の設定を確認してください。InterfaceのPrivateKeyはローカルの秘密鍵、PeerのPublicKeyはリモート側の公開鍵です。手元にあるのがクライアント用ではなくサーバー用の設定なら、2つを入れ替えるのではなく、現在の端末に割り当てられたクライアント用の設定情報を入手してください。
AllowedIPsを全範囲にしたのに、リクエストが直接接続されるのはなぜですか?
まずHomeでGlobal Routingを確認してください。ConfigではルールによってリクエストをWireGuardに渡すかどうかが決まります。Directでは、AllowedIPsを全範囲にしてもトンネル経由にはなりません。適用中のルールとポリシーを確認し、IPv4とIPv6の範囲がそれぞれ含まれているかも調べてください。
元の設定にあるDNSをAddressに入力すればよいですか?
別の項目に入力してください。Addressはリモートアドレスまたはローカルのトンネルアドレスを示し、どちらかは項目のグループによって異なります。DNSは名前解決に使うサーバーです。現在のConfigにあるDNS設定と、そのサーバーへの通信経路を確認してください。DNSがトンネル内のネットワークにある場合は、WireGuard経由でそのアドレスに到達できる必要があります。
画面をロックしてから戻ると、接続まで時間がかかります。MTUを変えると改善しますか?
まず、アイドル状態の間にNATマッピングが失効していないかを確認します。元の設定のPersistentKeepaliveを調べ、リクエストを再送した際にHandshakeが回復するか観察してください。MTUが調整するのはパケットサイズであり、NATマッピングを維持するものではありません。ネットワークを切り替えた後も接続できない場合は、EndpointとUDP通信を確認してください。
トラブル時の記録には、ネットワークの種類、Global Routingのモード、対象のアドレス種別、MTU、失敗した段階だけを残すのがおすすめです。「Handshake未成立」「Handshake成立後にデータが届かない」「ドメイン名でのアクセスだけ失敗」の3種類を比較できます。鍵、ルーティング、名前解決を同時に何度も変更すると、テスト結果を比較できなくなるため避けてください。