Shadowrocket WireGuard設定ガイド：PrivateKey・PublicKey・AllowedIPsの意味

この記事の要点

WireGuardを設定する際は、まず自分の端末のID、接続先のID、トンネルアドレスを区別し、EndpointとAllowedIPsを確認します。自分で用意したサービス事業者の設定情報、または自分で管理するエンドポイント情報をお持ちの方向けに、標準的なWireGuardの各項目をShadowrocketでの追加手順に対応づけて解説します。鍵の誤り、UDPの疎通不良、ルーティング範囲の不足、MTUの不適合を見分ける方法も紹介します。

1. Add ServerからWireGuardを追加する

ShadowrocketのWireGuard設定には、互いに対応した複数のパラメータが必要です。接続先のアドレスとポートだけでは接続できません。端末のPrivateKeyに対応するPublicKeyが接続先に登録されており、トンネルアドレスと許可するアドレス範囲も接続先の設定と一致している必要があります。以下のアドレスは項目の説明用であり、そのまま接続には使えません。

パラメータを整理する

既存の設定から[Interface]と[Peer]を区別します。前者には端末のPrivateKeyやAddressなど、後者には接続先のPublicKey、Endpoint、AllowedIPsなどが含まれます。上書きして照合できなくならないよう、先に元の設定を保存してください。
タイプを選択する

Home → 右上の「+」→ Add Server → Typeと進み、WireGuardを選択します。Typeを確認してから各項目を入力してください。WireGuardの鍵を別のプロトコルのパスワード欄に入力しないでください。
各項目を対応づける

Endpointのホスト名とポートをAddress、Portに対応させます。InterfaceのPrivateKeyとPeerのPublicKeyは、それぞれ対応する鍵の項目に入力します。トンネルIPはローカルアドレスの項目に入力し、接続先のAddressには入力しないでください。項目のグループ分けや表示は、現在のアプリ画面に従ってください。
保存して確認する

保存後、Homeに戻って対象の設定を選び、Global Routingを確認してから接続スイッチをオンにします。システムの案内に従ってVPN構成の追加を許可したら、Connectivity Testと実際の接続先へのアクセスでそれぞれ確認します。スイッチがオンになったことだけで、接続先とのハンドシェイク成功とは判断できません。

項目を一つずつ確認する場合は、設定を手動で追加すると便利です。既存のサブスクリプションから取得した設定の場合は、更新によって手動変更が上書きされないか、あらかじめ確認してください。トラブルシューティングでは別のコピーを保存し、変更箇所を記録します。本サイトでは接続先やサブスクリプションを提供・販売・推奨していません。以下では、お手元にある設定の確認方法のみを説明します。

2. PrivateKeyとPublicKey：どちらの端末の鍵かを確認

WireGuardは鍵ペアを使って認証します。端末のPrivateKeyとPublicKeyが一組になり、接続先にも独自の鍵ペアがあります。ShadowrocketのPeer PublicKey欄に入力するのは接続先の公開鍵であり、現在のPrivateKeyから生成される端末側の公開鍵ではありません。手動設定で特に取り違えやすい項目です。

端末側のInterface

PrivateKey: 端末側の秘密鍵です。端末のIDとして使われるため、安全に保管してください。
PublicKey: 端末側のPrivateKeyから生成され、接続先にPeerとして登録する鍵です。
Address: 端末側のトンネルアドレスです。例：10.66.0.2/32。公開エンドポイントではありません。

端末側のPrivateKeyを変更した場合は、接続先に登録した端末側のPublicKeyも更新する必要があります。

接続先のPeer

PublicKey: 接続先の公開鍵です。クライアント側のPeer PublicKey欄に入力します。
PresharedKey: 任意の追加共有鍵です。有効にする場合は、両端で同じ値を設定してください。
Endpoint: 接続先のホスト名と到達可能なUDPポートです。例：192.0.2.10:51820。

クライアントに接続先のPrivateKeyは不要です。両端の秘密鍵を交換しないでください。

標準的なWireGuardの鍵は、32バイトのデータをBase64で表したものです。通常は44文字で、末尾が=になります。貼り付ける際は末尾の文字を残し、引用符や空白、改行を加えないでください。長さや見た目が正しくても、適切なPeerの鍵であるとは限りません。

3. Address・Endpoint・DNS：3種類のアドレスを混同しない

標準設定ファイルのAddressはトンネル内部のアドレスを指します。一方、サーバー追加画面のAddressは通常、接続先ホストのアドレスとして使われます。同じ英単語でも文脈によって意味が異なるため、項目のグループを確認してください。10.66.0.2/32を接続先ホストとして入力しても、公開エンドポイントには接続できません。

設定の記述	例と意味	入力時の確認事項
Interface Address	`10.66.0.2/32`：端末側のトンネルIPv4アドレス。	元の設定に従ってローカルアドレス欄に入力し、アドレスとプレフィックス長をあわせて確認します。
Peer Endpoint	`192.0.2.10:51820`：接続先ホストとUDPポート。	画面でAddressとPortが分かれている場合は、ホストと`51820`をそれぞれ入力します。
IPv6 Endpoint	`[2001:db8::10]:51820`：角括弧でホストとポートを区切る形式。	ホストとポートが別欄の場合、両方を含む文字列をホスト欄に入力しないでください。
DNS	名前解決を行うサーバーのアドレス、または名前解決の設定です。	名前解決の経路で接続先に到達できることを確認します。DNSはEndpointやトンネルアドレスの代わりにはなりません。

192.0.2.10と2001:db8::10はドキュメント用の例示アドレスです。実際のポートには自分の設定値を使ってください。51820はよく使われる例であり、WireGuardで必須のポートではありません。WireGuardはUDPを使用するため、一般的なTCPポートのテストに成功しても失敗しても、その結果だけではUDPエンドポイントの可用性を判断できません。

Endpointにドメイン名を使う場合、クライアントはハンドシェイクデータを送る前に名前を解決する必要があります。エンドポイントのドメイン名自体を解決できない場合は、まず現在のネットワークの名前解決環境を確認してください。エンドポイントに到達できる一方でWebサイトのドメインだけ開けない場合は、DNSリクエストの実際の経路を確認します。この2つの問題を「鍵の不具合」とひとまとめにしないでください。

4. AllowedIPsとGlobal Routing：2つの選択を分けて確認する

WireGuardのPeerにおけるAllowedIPsは、アドレス範囲をPeerに対応づけるとともに、受信データの送信元アドレス範囲を検証するために使われます。アプリのドメインルールでも、「接続を許可する接続先サーバーの一覧」でもありません。たとえば10.66.0.0/24は1つのIPv4ネットワーク、0.0.0.0/0はすべてのIPv4アドレス、::/0はすべてのIPv6アドレスを表します。

指定したネットワークだけにアクセスする場合：既存の設定で10.66.0.0/24だけが許可されている場合、あらゆるインターネット上の宛先にこのPeer経由でアクセスできるわけではありません。接続先にも対応するルートとアクセス権限が必要です。
IPv4とIPv6の両方を使う場合：0.0.0.0/0にはIPv6は含まれません。デュアルスタックが必要なら、::/0、端末側のトンネルアドレス、接続先のIPv6転送機能をあわせて確認してください。
設定の対応関係を確認する：インポート形式によっては、AllowedIPsが内部設定に変換される場合があります。手動設定画面に同名の項目がなくても、別の入力欄に無理に入力せず、その形式が対応しているか、保存後の設定がどうなっているかを確認してください。
アプリのルーティングを確認する：Home → Global Routing → Configでは、現在の設定ルールに従って通信の処理方法が選ばれます。DIRECTに一致したリクエストは、AllowedIPsの範囲を広げても自動的にそのWireGuard設定経由にはなりません。

ShadowrocketのGlobal RoutingとWireGuardのPeerのアドレス範囲は、別々の設定です。一時的にProxyを選ぶとルールの影響を切り分けやすくなりますが、アプリの処理対象、トンネルのパラメータ、接続先ネットワークの機能に制約されます。Directを選んだ状態ではWireGuardの転送経路を検証できません。テスト後は元の設定に戻し、一時的な切り分け状態を長期設定として使わないでください。

5. MTUとPersistentKeepalive：症状に応じて調整する

MTUはトンネル内で送信できるデータパケットの最大サイズに影響します。カプセル化によるオーバーヘッドがあるため、適切な値は下位ネットワークや通信経路によって異なります。「小さなリクエストは成功するが、大きなページやデータ転送が止まる」など、パケットサイズの問題が疑われる場合にMTUを比較します。ハンドシェイクに失敗する場合は、まずEndpoint、UDP、鍵を確認してください。

元のMTU設定を維持する

MTUを少し下げる

元の値が1420の場合は、別のコピーを保存してから1380で比較テストできます。これはトラブルシューティングの例であり、実測結果ではありません。同じネットワーク、同じ接続先、同じ他のパラメータで試してください。改善しなければ元の値に戻します。

適しているケース：データの送受信はできるものの、大きなデータの転送が繰り返し止まる場合。

PersistentKeepaliveの単位は秒です。定期的に保活データを送信し、NATやファイアウォールのマッピングを維持しやすくします。25はよく使われる設定例ですが、実際には自分の設定要件に従ってください。再認証用のパスワードでも、速度を上げるスイッチでもありません。PublicKeyの誤りや到達できないポートは、設定しても解決しません。

しばらく通信がないと接続を再開しにくくなる場合に、保活設定とネットワークのマッピングを重点的に確認してください。
どの変更が症状に影響したか判断できなくなるため、MTUとPersistentKeepaliveは一度にどちらか一方だけ変更します。
Wi-Fiとモバイル通信を切り替えて試す場合は、それぞれの結果を記録し、異なるネットワークのデータを同じ比較として扱わないでください。

6. 両端の設定を対応づける：クライアントと接続先の確認リスト

片方で接続がオンになっていても、もう片方がそのIDを受け入れたとは限りません。トラブルシューティングでは、クライアントがどこに接続するか、接続先がどの端末を許可するか、戻りの通信がどのように端末へ到達するかをそれぞれ確認してください。特に、複数の端末で同じIDとトンネルアドレスを使い回さないでください。接続先が異なる送信元エンドポイント間でマッピングを更新し、接続が不安定になることがあります。

確認方法：端末側のInterfaceと接続先のPeerを照合する

Shadowrocket（端末側）

PrivateKeyは現在の端末のものです。対応するPublicKeyを接続先に登録済みです。
Peer PublicKeyは接続先のものです。Endpointのホスト名とUDPポートも正しい値です。
トンネルアドレス、アドレス範囲、DNSは既存の設定と一致しています。
Homeで正しい設定を選択し、Global Routingをテストの目的に合わせています。

接続先の設定

対応するPeerには、別の端末ではなく現在の端末のPublicKeyが登録されています。
端末ごとに固有のアドレスを割り当てます。例：10.66.0.2/32。戻りの経路も設定してください。
実際に待ち受けているUDPポートと、ファイアウォールで許可されているポートが一致しています。
外部ネットワークへのアクセスが必要な場合は、必要な転送設定、ルート、アクセス権限がそろっています。

まず鍵の対応関係を確認し、次にアドレスと転送設定を確認してください。クライアント側の項目を変更しても、接続先に必要な設定の代わりにはなりません。

7. よくある入力ミスと確認方法

Connectivity Testは到達性を判断するための補助機能です。単一の遅延値をスループットやハンドシェイクの状態とみなさないでください。検証時には、接続先、テスト方法、使用中のネットワークを記録します。接続先を自分で管理している場合は、接続先側の最終ハンドシェイク時刻や送受信カウンターも確認し、データが届いているかを判断してください。以下のQ&Aでは、すべての失敗が同じ項目に起因するとは限らないことを前提に、確認できる症状ごとに説明します。

PrivateKeyを保存するとすぐにエラーになります。まず何を確認すればよいですか？

Homeで対象の設定の編集画面を開き、PrivateKey =の行全体や引用符、改行までコピーしていないか確認します。通常、項目に入力するのは等号の後ろにある鍵の値だけです。末尾の=はBase64データの一部なので残してください。文字を適当に足して直そうとしないでください。

スイッチはオンなのに、データが送受信されないのはなぜですか？

まずHomeで対象の設定が選択されていることを確認し、次にGlobal Routingを確認します。その後、Endpoint、UDPポート、接続先のPublicKeyを確認してください。接続先を管理できる場合は、最終ハンドシェイク時刻と送受信カウンターも確認します。システムのVPNが起動したことだけでは、接続先が応答したとは判断できません。

内部アドレスにはアクセスできるのに、インターネット上のWebサイトが開けない場合は？

まずAllowedIPsが内部ネットワークだけを対象にしているか確認し、次にDNSと接続先の転送設定を個別に確認します。Global RoutingがConfigの場合は、対象の通信にどのルールが適用されているかも確認してください。AllowedIPsをすべてのアドレスに変更しただけで、接続先にインターネットへの転送機能があると判断しないでください。

接続をオフにしても自動で再接続します。項目の入力ミスですか？

Settings → On Demandを開き、現在のオンデマンド接続条件を確認します。手動で切り分ける間は関連する自動接続を一時停止し、Homeに戻って再テストしてください。On Demandは接続を開始するタイミングを決める機能です。WireGuardの鍵が正しいかどうかとは別の問題なので、自動接続の対処として鍵を変更しないでください。

別の端末では使えています。設定一式をコピーしてもよいですか？

まず接続先で2台の端末それぞれに別のIDとアドレスが割り当てられているか確認してください。端末ごとに異なるPrivateKeyを使用し、それぞれのPublicKeyを接続先に登録する必要があります。エンドポイントの情報が同じでも、ID一式をそのまま複製してよいわけではありません。別々の設定を保存し、同じネットワークで比較してください。

最終確認では、少なくとも次の3点を確認してください。対象のリクエストが想定した設定を経由すること、必要なアドレス範囲にアクセスできること、しばらく通信がない後も想定どおりに通信を再開できることです。確認が終わったら元の設定と変更履歴を保存し、トラブルシューティング中に作成した重複項目を削除します。サブスクリプションで設定を管理している場合は、次回の更新で確認済みのパラメータが上書きされないことも確認してください。