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

1. ローカルインターフェースとPeerを区別する

WireGuardは公開鍵で通信相手を識別し、暗号化したデータをUDPで送受信します。設定のローカルインターフェースは、端末の識別情報とトンネルアドレスを管理し、Peerは通信先となるリモート側を表します。両者の鍵を取り違えないようにしてください。端末側では自身のPrivate Keyを保持し、リモート側のPublic Keyを設定します。リモート側には、端末のPrivate Keyに対応するPublic Keyを登録する必要があります。

この記事では、利用者が有効な設定情報をすでに持っていることを前提としています。本サイトでは接続先やサブスクリプションを提供、販売、推奨していません。WireGuardの設定は、アドレスと共通パスワードを入力すれば完了するものではありません。少なくとも鍵の組み合わせ、ローカルトンネルアドレス、リモートエンドポイントを確認してください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2の認証情報をWireGuardに流用することはできません。

標準的なWireGuard設定の[Interface]と[Peer]は、各項目を理解するためのものです。Shadowrocketの[Rule]ルールセクションとして扱わないでください。設定をインポートする場合も、ファイル形式がクライアントでサポートされているか先に確認してください。拡張子が同じという理由だけで、異なる形式を使い回すことはできません。

2. Private Key、Public Key、アドレスの入力先

Private Keyは端末側の秘密情報です。既存の設定から省略せずにコピーし、前後の空白、改行、文字の欠落がないか確認してください。Private Keyを変更すると端末の識別情報も変わります。リモート側に古いPublic Keyが登録されたままでは、Endpointが正しくても正常に通信できません。接続を直すためだけに、むやみに鍵を再生成しないでください。

Addressの/32は単一のIPv4アドレスを示すプレフィックスです。IPv6の単一アドレスでは/128がよく使われます。これらのアドレスはリモートネットワークの設計に基づいて割り当てられるため、自宅のWi-Fiアドレスと異なるという理由でローカルネットワークのアドレスに変更しないでください。元の設定にIPv4とIPv6の両方がある場合は、リモート側と現在のネットワークの双方が対応しているか確認してください。

3. HomeでWireGuardを追加して確認する

ShadowrocketのHomeでは接続先を選択し、Configではルール設定を管理し、Settingsではアプリの設定を管理します。まずWireGuard自体を正しく設定してから、ルールによる振り分けを確認してください。画面の構成はアプリの更新で変わる場合があります。以下では操作の階層を示しています。元の設定にあるAllowedIPsやDNSなどが、編集画面に同じ名前で表示されるとは限りません。同名の入力欄がないからといって、関係のない項目に入力しないでください。

1. パラメーターを準備する

   手元の設定から、端末側のPrivate Key、トンネルAddress、リモート側のPublic Key、Endpoint、任意のPreshared Keyを確認します。照合できるよう、元の設定も保存しておいてください。

2. 種類を選択する

   Home → 右上の「+」→ Type → WireGuardの順に進みます。先に種類を選択してから項目を入力し、別のプロトコル用の編集画面に入力しないようにしてください。

3. エンドポイントを入力する

   Endpointのホスト名とポートを、AddressやPortなどのサーバー項目に対応させて入力します。たとえばドキュメント用のEndpoint 192.0.2.10:51820では、ホストは192.0.2.10、ポートは51820です。ここでのサーバーAddressとトンネルAddressは別のものです。

4. 鍵を確認する

   端末側のPrivate Keyとリモート側のPublic Keyを入力し、ローカルトンネルアドレスも確認します。Preshared Keyが元の設定にある場合はそのとおりに入力してください。設定がない場合、パスワードやPublic Keyで代用しないでください。

5. 保存してテストする

   保存したらHomeに戻り、対象項目を選択してGlobal Routingを確認します。最初のテストでは、対象を一つに絞って確認してください。診断中はSettings → On Demandで自動接続を一時的に無効にすると、手動で切断したあとに再接続されるのを防げます。

51820はWireGuardでよく使われる待受ポートですが、プロトコルで定められた必須ポートではありません。元の設定が443なら、対応するUDPエンドポイントに443を使用してください。それだけでTCPやHTTPSに対応しているとは限りません。ネットワークでUDPが遮断されている場合、ポート番号を変えてもリモート側が新しいポートで待ち受けていることにはなりません。

4. AllowedIPsとGlobal Routingは異なる階層の設定

標準的なWireGuardの仕様では、AllowedIPsは送信トラフィックをどのPeerに振り分けるかを決め、Peerから受信した復号済みトラフィックの送信元アドレスも制限します。一般的な0.0.0.0/0はすべてのIPv4アドレスを、::/0はすべてのIPv6アドレスを対象とします。10.7.0.0/24は指定したネットワークだけが対象です。ドメイン名の一覧でも、Webサイトへのアクセス権や利用料金の枠でもありません。

Shadowrocketには、Global RoutingとConfig内のルール設定もあります。アプリからのリクエストを選択した接続先に送るかどうかは、現在のルーティング設定とあわせて判断してください。元の設定に0.0.0.0/0が含まれていても、すべてのリクエストが必ずWireGuardを通るとは限りません。Sceneは状況に応じた設定の切り替えに使います。基本的な切り分けでは、まず明確なルーティング設定を一つ選び、条件を増やさないようにしてください。

以下はShadowrocketのルール構文の例で、WireGuard設定ではありません。DOMAIN-SUFFIXはドメインの末尾に一致し、IP-CIDRはIPネットワークに一致します。FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールは上から順に評価され、先に一致したリクエストはFINALまで進みません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,DIRECT

ここでのexample.comと192.0.2.0/24はドキュメント用の例です。GEOIPを使う場合はIPアドレスの地理情報データベースに依存する点を理解し、Peer、AllowedIPs、サーバー側の戻りルートの確認に代用しないでください。ルールの詳細はルールリファレンスをご覧ください。

5. MTUとDNS：接続後も通信できない場合の原因

MTUは、トンネルインターフェースで扱えるIPパケットの最大サイズを制限します。暗号化によるカプセル化で外側のヘッダーが加わるため、トンネルのMTUは通常、基盤となるリンクのMTUより小さくなります。1420はよく使われる目安ですが、すべてのWi-Fi、モバイルネットワーク、多重トンネルに適用できる固定値ではありません。まず手元の設定で指定されている値またはデフォルト値を使い、関連する症状がある場合に限って条件を管理しながら比較してください。

上記は症状の診断方法であり、実測結果ではありません。1380も万能な最適値ではありません。MTUを下げても再現性のある改善がなければ元の値に戻し、ほかの階層を確認してください。MTU、DNS、Endpoint、ルーティング設定を同時に変更すると、どの変更が影響したのか判断できません。

DNSはドメイン名をアドレスに変換する仕組みで、WireGuardの公開鍵ハンドシェイクには関与しません。標準設定のDNS項目は通常、クライアントが解釈します。Shadowrocketでの実際の名前解決は、現在のConfigにあるDNS設定もあわせて確認してください。トンネル内からしか到達できないDNSアドレスは、トンネル確立前の名前解決には使えません。Endpoint自体がドメイン名の場合は特に注意が必要です。

• まず、現在のネットワークでEndpointのドメイン名を解決できることを確認し、次にリモート側のUDPに到達できるか確認してください。
• ブラウザーでIPアドレスに直接アクセスしてDNSを判断しないでください。HTTPS証明書や仮想ホストが正しいドメイン名を必要とする場合があります。
• DNSを変更したら接続を確立し直してください。システムやアプリのキャッシュが比較結果に影響する場合もあります。

6. エンドポイント、ハンドシェイク、データ、ルールの順に切り分ける

アプリに接続済みと表示されることや、システムにVPNアイコンが表示されることから分かるのは、ローカルの接続状態までです。リモート側が鍵を受け入れたことや、実際のリクエストが宛先に届いたことを単独で証明するものではありません。WireGuardは通信がない間、何も表示せず待機する場合があります。対象を明確にしたリクエストでテストしてください。リモート側の管理権限がある場合は、最終ハンドシェイク時刻と送受信カウンターも確認できます。

1. エンドポイント層：ホスト名またはIPアドレスが正しいこと、ポートがリモート側の待受ポートと一致すること、現在のネットワークで該当するUDP通信が許可されていることを確認します。ドメイン名を解決できても、UDPポートに到達できるとは限りません。
2. ハンドシェイク層：端末のPrivate Keyに対応するPublic Keyがリモート側に登録されていること、リモート側のPublic Keyが正しいこと、任意のPreshared Keyを使う場合は両端で一致していることを確認します。鍵の長さが同じに見えるだけでは、正しい組み合わせかどうか確認できません。
3. データ層：ハンドシェイクできても通信できない場合は、トンネルアドレス、AllowedIPs、リモート側の転送設定、ファイアウォール、戻りルートを確認します。リモート側でNATが必要か、明示的な戻りルートが必要かは、ネットワークの設計によって異なります。
4. ルール層：Global Routing → Proxyと、Configで同じリクエストを送った結果を比較します。Configでのみ失敗する場合は、まずルールの一致状況と参照先の接続ポリシーを確認してください。最初に鍵を交換する必要はありません。
5. 安定性の層：しばらく通信がないと切断される場合は、NATマッピングとキープアライブの要否を確認します。標準設定のPersistentKeepaliveの単位は秒で、25秒はよくある例ですが、すべての接続で有効にする必要はありません。元の設定で指定され、クライアントが対応している場合に限って調整してください。

7. よくある入力ミスと保存前の確認

手動設定でよくある問題は、選べるプロトコルが少ないことではなく、項目の役割を取り違えることです。保存前に項目を一つずつ見直し、特にAddressと表示されるサーバーアドレスとトンネルアドレスを区別してください。サブスクリプションにWireGuardの項目が含まれている場合、手動で変更しても次回更新時に上書きされることがあります。別途記録を残し、設定情報がどこで管理されているか先に確認してください。

• 端末側のPublic KeyをPeerに入力する：PeerのPublic Keyはリモート側のものです。端末側の公開鍵はリモート側に登録します。
• EndpointにWebページのURLを入力する：https://やページのパスを付けないでください。ホストとポートの入力欄が別れている場合は分けて入力します。IPv6アドレスをコロンだけで安易に分割しないでください。
• トンネルアドレスのプレフィックスを省略する：元のAddressにあるプレフィックスをそのまま維持してください。画面で項目が分かれている場合は、それぞれの入力形式に従い、割り当て内容を変更しないでください。
• AllowedIPsでアプリのルールを代用する：IPプレフィックスとDOMAIN-SUFFIXは異なる階層の設定です。AllowedIPsにドメイン名を入力することはできません。
• Preshared Keyをログインパスワードとして扱う：設定がない場合は未設定のままにしてください。設定がある場合は、両端で合意された鍵を使用する必要があります。
• 自動接続を確認しない：Settings → On Demandは接続を開始する条件に影響しますが、鍵、Peer、[Rule]の内容は変更しません。診断が終わったら、通常使っている自動接続の設定に戻してください。

確認が終わったら、まず対象を一つに絞り、選択したWireGuard接続で通信できることを確かめます。その後、Configによる振り分けと通常の自動接続設定を戻してください。ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリで、主にiPhoneとiPadで利用されています。価格、システム要件、その他のAppleデバイスとの互換性はApp Storeの表示をご確認ください。アプリの買い切り購入は回線サービスの契約とは別です。アプリを購入しても、すでに利用している接続サービスや設定に代わるものではありません。