利用中のサービスとWireGuard設定がある場合は、Home → + → Type → WireGuardからサーバーを追加します。クライアントのPrivate Key、対向側のPublic Key、トンネルアドレス、Endpointは、対応する設定一式を使用してください。DNSは名前解決を、MTUはカプセル化後のパケットサイズに影響します。各項目の取得元や入力順、症状ごとの確認方法を説明します。手動入力や既存設定の確認にお役立てください。
1. 入力前に設定の入手元と項目の区分を確認
ShadowrocketのWireGuardでは、有効な対向側の設定が必要です。サーバーアドレスだけでは接続できません。利用中のサービスと設定を用意するか、該当するWireGuardの対向側を管理していることが前提です。本サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。手元の情報が通常のサブスクリプションURLだけの場合は、WireGuard形式の設定が含まれているか確認してください。サブスクリプションURLをサーバーアドレス欄に入力しないでください。
WireGuardの設定は一般に、[Interface]と[Peer]の2つのセクションで構成されます。前者はローカルの識別情報とトンネルインターフェース、後者はリモート側の識別情報と接続先を記述します。Shadowrocketではこれらの情報をサーバー編集画面の各項目に入力します。項目の並びや表示名は現在の画面に従い、以下では照合しやすいよう設定ファイルのキー名をそのまま記載します。
設定を受け取ったら、まず安全な場所にバックアップを保存してから入力してください。公開の質問にPrivate Key、Preshared Key、サブスクリプションURL全体を載せないでください。接続権限に関わる情報が含まれている場合があります。形式の確認だけなら、具体的な鍵を公開せず、文字数や空白の有無、記載されているセクションを伝えれば十分です。
2. Private KeyとPublic Key:ローカルの秘密鍵と対向側の公開鍵を取り違えない
[Interface]のPrivateKeyはクライアントの秘密鍵で、対向側に登録されたクライアント公開鍵と対応している必要があります。[Peer]のPublicKeyはサーバーの公開鍵で、リモート側の識別に使います。どちらもBase64形式の文字列に見えますが用途は異なります。見た目だけで判断したり、クライアント自身の公開鍵を対向側のPublic Keyに入力したりしないでください。
ローカルの識別情報とアドレス
- PrivateKey
- クライアント設定の[Interface]から取得します。サーバーの秘密鍵ではありません。
- Address
- 対向側からこのクライアントに割り当てられたトンネルアドレスを使います。
- DNS
- 元の設定に記載されたリゾルバーを参照し、Shadowrocketで実際に有効なDNS設定も確認してください。
- MTU
- 設定に明記された値を優先し、記載がない場合は任意の値を指定しないでください。
ローカルアドレスと鍵は、同じ有効な設定から取得してください。異なる端末の情報を混在させないようにします。
リモート側の識別情報と接続先
- PublicKey
- [Peer]から取得する、リモートサーバーの公開鍵です。
- Endpoint
- リモート側のドメイン名またはIPアドレスと、実際に待ち受けているUDPポートです。
- PresharedKey
- 元の設定に記載されている場合のみ入力します。双方で値を一致させてください。
- PersistentKeepalive
- 元の設定に従ってKeepaliveの間隔を設定します。有効な鍵の代わりにはならず、誤ったポートも修正できません。
PublicKeyとPresharedKeyは別々の項目です。相互に置き換えることはできません。
WireGuardの標準的な鍵はBase64で44文字になることが多く、末尾に=が付く場合があります。文字数が合っていても、鍵の組み合わせが正しいとは限りません。貼り付ける際は前後の空白、引用符、改行を取り除き、鍵そのものに含まれる+、/、=などは残してください。
- クライアントの秘密鍵を再生成した場合は、そこから導出される新しいクライアント公開鍵を対向側にも登録する必要があります。端末側だけを変更しても、接続が復旧するとは限りません。
- サーバー側の
[Interface]からPrivateKeyをコピーしてクライアントに入力しないでください。該当クライアント専用に割り当てられた設定を使用します。 - 元の設定にPresharedKeyがない場合は未設定のままにしてください。PrivateKeyやPublicKeyを代わりに入力しないでください。
- 2台の端末で同じクライアント識別情報を同時に使わないでください。対向側が直近に通信したエンドポイントへ応答を送る場合があり、接続が交互に切れることがあります。
3. Address、Endpoint、ポート:トンネル内外のアドレスを区別する
Addressはトンネル内部のアドレス、Endpointはリモート側への接続に使う外部の接続先です。互いに置き換えることはできません。たとえば、クライアントに10.66.0.2/32が割り当てられ、Endpointが192.0.2.10:51820の場合、前者はトンネル内でのローカルアドレス、後者は暗号化されたUDPパケットの送信先です。このEndpointには文書用の予約アドレスを使用しているため、実際には接続できません。
| 項目 | 形式の例 | 入力時の確認ポイント |
|---|---|---|
| Address | 10.66.0.2/32 | クライアントへの割り当て情報を使用します。画面でアドレスとプレフィックスを別々に入力する場合は、それぞれ該当する欄に入力してください。 |
| Endpointのホスト | 192.0.2.10 | リモート側のドメイン名またはIPアドレスを入力します。https://やURLのパスは付けません。 |
| Endpointのポート | 51820 | 実際のUDP待ち受けポートを入力します。例の値は共通のデフォルトではありません。 |
| IPv6 Endpoint | [2001:db8::10]:51820 | アドレスとポートをまとめて入力する場合は、IPv6アドレスとポートを角括弧で区別します。項目が分かれている場合は画面の指示に従って入力してください。 |
/32はIPv4のプレフィックス長であり、ポートではありません。IPv6の単一アドレス設定には/128が使われる場合もあります。画面でIPv4アドレスのみを求められた場合、ポートやEndpoint全体を貼り付けないでください。IPv6アドレスは元の設定に明記され、ネットワークが対応している場合に限り入力します。存在しないアドレスを推測して追加しないでください。
WireGuardのAllowedIPsは、Peerが扱う宛先範囲と送信元の検証範囲を示すもので、クライアントのAddressを別の形で記述したものではありません。元の設定に0.0.0.0/0や::/0が含まれていても、そのサーバーを実際の通信に使うかどうかは、ShadowrocketのGlobal RoutingやConfigのルールと合わせて判断する必要があります。この2項目だけで、すべてのアプリの通信がそのサーバーを経由すると断定することはできません。
4. HomeからWireGuardを追加して、基本動作を確認する
初回はサーバーを1つだけ設定し、ルーティング、DNS、MTUを同時に変更せずに確認します。問題が起きたとき、どの変更が影響したのか切り分けやすくなります。WireGuardサーバーの追加には以下の手順を使います。Configは設定ファイルやルールを扱う画面なので、2つの入口を混同しないでください。
-
タイプを選択
Home → + → Type → WireGuardに進みます。編集画面に戻ったら、タイプがWireGuardのままであることを確認してから入力します。
-
接続先を入力
Endpointのホストとポートを、それぞれ該当する欄に入力します。たとえば文書用の例192.0.2.10:51820は、アドレスとポートに分けます。実際の設定では有効な接続情報を使用してください。
-
鍵を確認
クライアントのPrivate Keyと対向側のPublic Keyを入力し、元の設定に従ってローカルのトンネルアドレスを追加します。Preshared Keyは明記されている場合のみ入力してください。
-
保存して選択
サーバーを保存し、Homeに戻って該当項目を選択します。初回接続時は、システムの案内に従ってVPN構成の追加を許可してください。許可はシステムVPN構成の作成を認めるもので、リモート側への到達を保証するものではありません。
-
接続を確認
Home → Global Routingで一時的にProxyを選択し、接続を開始して、アクセス権のあるテスト先に接続します。確認後はGlobal Routingを元の設定に戻し、通常のルールによる振り分けも確認してください。
Global RoutingのProxyはルールによる変数を減らすために使えますが、サーバー自体のアクセス権やネットワーク上の制限を回避するものではありません。DirectではWireGuardが通信を運んでいるか確認できません。Configを使う場合は、テスト先がそのサーバーを使うポリシーに実際に一致しているか確認してください。システムにVPN接続中と表示されても、それはローカルのトンネル状態を示すだけで、リモート側との鍵交換やサービスへのアクセス成功を意味しません。
5. DNSとMTUの設定:まず元の値を使い、必要なら個別に調整
DNSはドメイン名の名前解決を担い、鍵の誤りを修正するものではありません。従来のWireGuard設定に記載されたDNSは、その設定を使用するアプリが解釈することが多く、プロトコルのハンドシェイク項目ではありません。WireGuardの設定をShadowrocketに手動入力する場合、元のファイルにあるDNSが現在の設定に自動反映されるとは限りません。Settings → DNSと現在のConfigのDNS設定も確認し、実際に有効な設定に従ってください。
- Endpointにドメイン名を使う場合、接続の確立前にその名前を解決できる必要があります。利用できる唯一のリゾルバーが未確立のトンネル内部にあると、名前解決が接続に依存する状態になることがあります。元の設定における名前解決の設計を確認してください。
- 管理対象の接続先へIPアドレスでアクセスでき、ドメイン名では失敗する場合は、まずDNSを確認してください。ただし、HTTPSでIPアドレスに直接アクセスすると、証明書や仮想ホストの設定が原因で失敗することがあります。この現象だけでDNSの問題と断定しないでください。
- 内部ドメインの名前解決にサービス提供元指定のDNSが必要な場合、別のネットワークのリゾルバーをそのまま使うと、トンネル接続後も内部リソースにアクセスできないことがあります。
MTUはインターフェースで扱える最大パケットサイズです。WireGuardは外側のカプセル化によるオーバーヘッドを加えるため、トンネル内部のパケットサイズは経路の許容サイズに制限されます。MTUが大きすぎると、小さなリクエストは通る一方で大きなページの表示やアップロードが止まることがあります。小さすぎる場合は分割と処理の負荷が増えます。こうした症状はパケットロスやサーバー負荷でも起きるため、「読み込みが遅い」というだけでMTUが原因と判断しないでください。
元の設定を使う、またはデフォルトのままにする
推奨元の設定にMTUが明記されていれば、まずその値を使います。記載がなければ、アプリのデフォルトの処理を優先し、ネット上でよく見かける値をすべての接続に共通する値として指定しないでください。
適するケース:初回入力時、接続が安定している場合、大きなパケットに関する再現性のある問題がまだない場合。
MTUを手動で下げる
元の値で、小さなリクエストは通るのに大きな転送が止まる症状を繰り返し確認できる場合のみ試してください。たとえば元の値が1420なら、結果を記録したうえで1380を試します。これらはテスト例であり、最適値の実測結果ではありません。
適するケース:同じネットワーク、同じ接続先で問題を再現でき、毎回MTUだけを変更できる場合。
テストごとにネットワークの種類、元のMTU、変更後の値、同じ操作での結果を記録します。下げても安定して改善しない場合は元の値に戻し、UDPの到達性、パケットロス、サーバー側のルーティングを確認してください。DNSやポートも同時に変更すると、接続が復旧しても原因を特定できません。
6. 症状に応じたトラブルシューティング:鍵からルーティングまで順に確認
まず接続の基本条件を確認し、その後にサービスへのアクセスを調べます。ポートへの到達性、鍵の対応、アドレス、対向側の転送と戻り経路を確認してから、DNSやルールによる振り分けを調べてください。サーバーを自分で管理している場合は、対向側の最終ハンドシェイク時刻や送受信カウンターも確認できます。利用中のサービス提供元が管理している場合は、個人情報を伏せたうえで時刻と症状を伝えてください。
| 症状 | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| 起動後も通信がタイムアウトする | Endpoint、UDPポート、双方の鍵、PresharedKey | 同じ元設定を参照して項目を1つずつ照合します。通常のWebページが開けても、そのUDPポートに到達できるとは限りません。 |
| 対向側でハンドシェイクを確認できるが、アクセスできない | Address、対向側のAllowedIPs、転送、戻り経路 | クライアントのアドレスが割り当て範囲内か確認し、対向側で該当するルートとアクセス権を確認します。 |
| 一部のドメインにアクセスできない | DNS、Configのルール、接続先のアクセス権 | 実際に使われているリゾルバーとポリシーを確認します。Private Keyは変更しないでください。 |
| 小さなリクエストは通るが、アップロードや大きなページの表示が止まる | 経路MTU、パケットロス、サーバーの状態 | ネットワークとテスト先を固定し、元の値を記録してからMTUだけを調整します。 |
| 2台の端末で交互に接続が切れる | クライアントの鍵やアドレスを使い回していないか | 端末ごとに異なる登録済みの識別情報とアドレスを使い、それぞれ個別に確認します。 |
| 更新後に手動で変更した項目が消える | サブスクリプション管理の対象か確認 | サブスクリプション更新で該当項目が上書きされていないか確認します。個別にテストする場合は、手動で追加した項目を別に保存してください。 |
Proxyでは正常に動作し、Configに戻すと失敗する場合は、WireGuardの鍵を再生成するのではなく、実際に適用されたルールとポリシーを確認してください。たとえばDOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインに一致します。IP-CIDRはIPアドレスの範囲で、GEOIPはIPの地理情報データベースで照合し、FINALはそれ以前のルールに一致しなかった接続に適用されます。ルールは上から順に処理されます。接続先に適用されるポリシーは現在の設定で確認してください。
WireGuardはサーバーアドレスとポートだけで設定できますか?
できません。対応するクライアントのPrivate Key、対向側のPublic Key、ローカルのトンネルアドレスが必要です。対向側にも対応する識別情報を登録する必要があります。PresharedKeyが設定されている場合は、双方の設定を一致させてください。
PersistentKeepaliveを25にすると必ず安定しますか?
25秒はNATのKeepalive間隔としてよく使われる例であり、必須の標準値ではありません。一部のネットワークでUDPのマッピング維持に役立つことがありますが、定期的にパケットを送信します。鍵やポートの誤り、接続をサポートしていないネットワークは解決できません。まず元の設定に従ってください。
サブスクリプション更新後に確認すべき項目は?
まずEndpoint、Public Key、クライアントアドレス、PresharedKeyが新たに追加されていないかを確認し、選択中のサーバーとGlobal Routingも確認します。元の項目がサブスクリプションで管理されている場合、手動の変更は次回更新時に上書きされることがあります。一時的な変更を恒久的な設定として扱わないでください。