Shadowrocket WireGuard設定ガイド｜Private Key・Peer・MTUの項目を解説

InterfaceとPeerを区別する

WireGuardの設定は通常、[Interface]と1つ以上の[Peer]セクションで構成されます。Interfaceはローカル側のトンネル識別情報とアドレス、Peerは通信相手を表します。提供元の設定をShadowrocketに入力する前に、まず役割ごとに項目を整理してから、Homeでレコードを追加しましょう。項目名にKeyやAddressが含まれているというだけで、すぐに貼り付けないでください。

この記事は、利用可能な設定を提供元からすでに入手していることを前提としています。Shadowrocketは買い切りの商用アプリですが、アプリの購入と通信サービスの契約は別です。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。WireGuardの各項目が有効かどうかは、両端の設定が対応しているかによって決まります。アプリを購入しても、利用可能なリモートPeerが自動で用意されるわけではありません。

Private Key・Public Key・Preshared Key

PrivateKeyとPublicKeyは、対になって使用する識別情報です。ローカル側の秘密鍵に対応する公開鍵を、リモート側に登録する必要があります。一方、ローカル側の設定にあるPeerのPublic Keyには、リモート側の公開鍵を指定します。これは両端がお互いを識別するための関係であり、同じ公開鍵をすべての項目にコピーするものではありません。

WireGuardの標準鍵は32バイトのデータで、一般的なテキスト表記は44文字のBase64文字列です。通常は末尾に=が付きます。文字数が合っていても、現在のアカウントやPeerに対応する鍵であるとは限りません。コピー時は末尾の文字を残し、誤って含まれた引用符、改行、前後の空白を取り除いてください。鍵の値だけを受け付ける入力欄に、PrivateKey =を含む行全体を入力しないでください。

• Private Key：元の設定のInterfaceセクションからコピーします。Public Keyで代用できません。また、公開するスクリーンショットや問い合わせ記録に載せないでください。
• Public Key：対象のPeerセクションからコピーします。リモート側の鍵が変更された場合は、サーバーアドレスだけでなく公開鍵も更新してください。
• Preshared Key：追加で使用する任意の対称鍵です。元の設定に記載されている場合は両端で同じ値を入力します。記載がない場合、自分で生成して片側だけに設定しないでください。
• ローカル側の秘密鍵を再生成：対応するローカル側の公開鍵も変わります。リモート側の登録情報も更新しない限り、既存の認証関係は維持されません。

AddressとEndpoint：別のアドレスとして扱う

InterfaceのAddressはトンネル内のアドレスです。例：10.66.0.2/32。この/32はIPv4のプレフィックス長であり、ポート番号ではありません。EndpointはWireGuard通信を確立するために接続するリモート側のネットワークアドレスで、通常はドメイン名またはIPアドレスとUDPポートの組み合わせです。役割が異なるため、画面にどちらもAddressと表示されていても、設定内の位置を確認してください。

表中のアドレスは形式の説明用であり、実際のサーバーとして使用できません。ポート51820はよく使われる設定値ですが、必須ではありません。元の設定に別のポートが記載されている場合は、その値を入力してください。Endpointにhttps://を付けたり、サブスクリプションのURLを入力したりしないでください。ドメイン名を使う場合は、リモート側へWireGuardのハンドシェイクを送信する前に、そのドメインを名前解決できる状態にしておく必要があります。

Homeで追加して項目ごとに確認する

アプリを操作する前に、元の設定を保存してください。以下は、すでに用意されているWireGuardの値を手動で入力する手順です。既存のサブスクリプションで管理しているレコードの場合、更新時に設定が上書きされるかどうかを先に確認してください。画面の構成によっては、トンネルの各項目が個別に表示されます。確認時はInterfaceとPeerのどちらに属する項目かを見て、設定ファイルのセクション名を値として入力しないようにしましょう。

1. 設定値を整理する

   InterfaceのPrivateKeyとAddress、PeerのPublicKeyとEndpointをそれぞれ控えます。PresharedKey、MTU、DNSがある場合は、それらも記録してください。Peerが複数ある設定では、どのPeerを入力するか先に確認します。

2. 種類を選択する

   Home → 右上の「+」→ Type → WireGuardの順に進み、レコードのメモとリモートアドレス情報を入力します。メモはレコードの識別用であり、鍵認証には使用されません。

3. 各項目の役割を確認する

   ローカル側のPrivate KeyとトンネルAddress、リモート側のPublic Keyを入力し、残りの項目も元の設定に合わせます。保存前に1項目ずつ照合してください。特にEndpointのPortに、トンネルのプレフィックス長を誤入力していないか確認します。

4. 他の設定と切り分けてテストする

   Homeに戻って対象のレコードを選び、一時的にGlobal RoutingをProxyに設定して接続し、到達可能と分かっている宛先にアクセスします。テスト後はGlobal Routingを元の設定に戻し、一時的な設定を日常利用に残さないようにしてください。

5. 自動接続を確認する

   手動で切断しても再接続する場合は、Settings → On Demandを確認してください。テスト中は、自動接続を引き起こす可能性のある条件をいったん無効にし、確認後に必要な設定を戻します。

システムのVPN状態が「接続済み」でも、リモート側とのハンドシェイクが成功したとは限りません。まず確認できるのは、ローカル側のVPNセッションが確立したことです。リモート側とデータを送受信できるかは、実際のリクエスト結果、参照可能なハンドシェイク記録、送受信カウンターをあわせて判断してください。接続スイッチがオンになっただけで、鍵やEndpointの確認を省略しないようにしましょう。

AllowedIPsとGlobal Routingの役割

標準的なWireGuard設定では、AllowedIPsによってアドレス範囲を特定のPeerに対応付け、データ受信時の送信元アドレス検証にも使用します。0.0.0.0/0はすべてのIPv4アドレス範囲、::/0はすべてのIPv6アドレス範囲を表します。ただし、この値だけでリモート側が該当するプロトコルの転送に対応しているとは限りません。

一方、ShadowrocketのGlobal Routingは、アプリがリクエストの処理経路をどう選ぶかを決めます。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定に従った処理、Sceneは選択中のシーンに従った処理です。AllowedIPsはConfig内のドメインルールではありません。アドレス一覧にDOMAIN-SUFFIXやFINALを記述しないでください。

• Proxyでは使えるが、Configでは使えない：まず現在のConfigで適用されるルール、対象のポリシー、選択中のサーバーを確認してください。すぐにWireGuardの項目が間違っていると判断する必要はありません。
• Directでは使える：対象に現在のネットワークから直接接続できることを示すだけで、WireGuardのPeerが正常に動作している証拠にはなりません。
• IPv6の宛先だけ失敗する：トンネルのIPv6アドレス、Peerのアドレス範囲、リモート側のIPv6転送条件がすべて設定されているか確認してください。
• 元の設定に複数のPeerがある：複数のPeerのPublic Key、Endpoint、AllowedIPsを1つのレコードに混在させないでください。元の設定で対応付けられている組み合わせを維持します。

MTU：まず元の値を使い、症状に応じて調整

MTUはトンネルインターフェースで扱えるIPパケットの最大サイズです。WireGuardはデータをUDPでカプセル化するため、外側にはIP、UDP、プロトコル自体のヘッダー分の領域も必要です。追加の拡張を含まない一般的なデータでは、外側がIPv4の場合のオーバーヘッドは約60バイト、IPv6の場合は約80バイトです。実際に利用できる値は、接続ネットワークや通信経路全体の条件にも左右されます。

1420は一般的な目安であり、すべてのネットワークに最適な値ではありません。元の設定にMTUが明記されている場合は、まずその値を入力してください。記載がなければ、アプリのデフォルト設定を維持するのが基本です。ハンドシェイクや小さなリクエストは正常でも、大きなページの読み込みやアップロードが続けて止まる場合に限り、MTUを調査対象にします。MTUを下げても、誤った鍵の修正にはなりません。

1. 現在のMTUと再現する宛先を記録し、同じネットワークで小さなリクエスト、大きなページ、アップロードをそれぞれ試します。
2. ほかの項目は変更せず、たとえば1420から1380に変更し、再接続後に同じリクエストを繰り返します。これは切り分け方法の例であり、実測結果ではありません。
3. 症状が改善しない場合は元の値に戻し、UDPの到達性、DNS、リモート側の転送設定を確認します。改善した場合は、Wi-Fiとモバイル通信を切り替えたときの動作も検証してください。

DNS：Endpointの名前解決とトンネル内の名前解決を区別する

WireGuardの暗号化プロトコル自体はDNSを配布しません。一般的な設定にあるDNSは、クライアント側で処理される追加設定です。元のファイルに記載されたDNSの値を入力した後も、実際の名前解決経路を確認するには、Shadowrocketの現在のConfigにあるDNS設定を確認する必要があります。項目があるだけで、すべてのクエリがそのDNSサーバーを通るとは限りません。

Endpointのドメイン名を接続前に解決することと、接続後にWebサイトのドメイン名を解決することは、別の段階です。Endpointがドメイン名で、指定したDNSサーバーへ接続するために未確立のトンネルが必要な場合は、最初の名前解決に使える経路が必要です。まず現在の接続ネットワークからリモート側のドメイン名を解決できることを確認し、その後、トンネル内のDNSに到達できるか調べてください。2種類の失敗を混同しないようにしましょう。

• 元の設定でプライベートネットワークのDNSアドレスを使用している場合は、対象のPeerを経由してそのアドレス範囲に到達できるか確認してください。プライベートネットワークのDNSサーバーには、直接接続ではアクセスできない場合があります。
• DNSの入力欄がIPアドレスを求めている場合、https://付きのDNSサービスURLをそのまま貼り付けないでください。形式の異なる値は置き換えられません。
• ドメイン名でアクセスできず、同じ宛先のIPアドレスには到達できる場合は、まず名前解決を確認してください。ただし、HTTPSサイトへIPアドレスで直接アクセスすると、証明書やサイトの選択が原因で失敗することがあります。これだけを判断材料にしないでください。
• 既存のサブスクリプション更新後に設定値が元に戻る場合は、レコードの取得元とConfigを確認してください。鍵、DNS、MTUを同時に変更すると、どの変更が影響したのか特定できなくなります。

よくある質問：症状から原因を絞り込む

作業後は、設定値の取得元、選択したレコード、Global Routingの状態、テストしたネットワーク、変更前後のMTUを含む、機密情報を伏せた確認記録を残してください。元のConfigとOn Demandの設定に戻した後、もう一度実際にアクセスし、一時的なテスト結果が通常の利用環境でも再現することを確認しましょう。