Shadowrocket WireGuardの設定方法｜Private Key・Public Key・Address・MTUを解説

この記事の要点

自分が利用するWireGuardサービスと設定情報をすでに持っており、Shadowrocketで各項目を確認したい方に向けた解説です。まず自分側と接続先の情報を区別し、Address、Endpoint、DNS、MTUを確認します。最後に接続、ルール、Webページへのアクセスをそれぞれ検証します。各項目を誰が提供するのか、誤入力がどこに影響するのかを説明するもので、そのまま接続に使える設定情報を提供するものではありません。

まずInterfaceとPeerを区別する

ShadowrocketのWireGuard設定には、利用中のサービスから提供された一式の設定情報を使用します。標準的なWireGuard設定ファイルでは、[Interface]に自分側のインターフェース、[Peer]に接続先の情報が記載されています。手入力する場合は、この2つを同じWireGuard設定に対応させてください。別の端末のPrivate Key、自分の端末のAddress、別サーバーのPublic Keyを混在させてはいけません。

WireGuardはUDPでトンネル通信を行います。サーバーのアドレスとポートはパケットの送信先を決め、鍵は通信する双方の認証に使われます。そのため、「アドレスを名前解決できる」「ポートが正しい」「認証に成功する」は、それぞれ別に確認する必要があります。

2つのセクション

標準設定はInterfaceとPeerで構成

32バイト

WireGuardの元データにおける秘密鍵と公開鍵の長さ

UDP

Endpointで使用する通信プロトコル

Private Key・Public Key・Preshared Key

[Interface]のPrivateKeyは自分側の秘密鍵で、画面上のPrivate Keyに対応します。この鍵から自分側の公開鍵を導出し、接続先にその公開鍵を登録します。自分側の秘密鍵はログインパスワードでも接続先の公開鍵でもありません。秘密鍵を変更した場合、接続先に登録された公開鍵も更新しなければ、従来どおり通信できません。

設定項目	入力する値	よくある間違い
`Interface.PrivateKey`	自分の端末が保持する秘密鍵。Private Keyに対応。	サーバーの公開鍵を入力する、またはコピー時に空白や引用符が混入する。
`Peer.PublicKey`	接続先の公開鍵。Public Keyに対応。	自分側の公開鍵を入力し、接続先の識別情報と一致しない。
`Peer.PresharedKey`	双方で追加設定する共有鍵。Preshared Keyに対応。	片方にだけ設定する、または双方の値が異なる。

Public Keyには接続先の公開鍵を入力します。「自分側のPrivate Keyから導出した公開鍵」ではありません。設定情報にクライアントとサーバーそれぞれの公開鍵が記載されている場合は、どのセクションにあるか確認してください。[Peer]内のPublicKeyが、ここで確認する接続先の識別情報です。

Preshared Keyは省略可能な項目ですが、片方だけで勝手に削除してよいという意味ではありません。元の設定に記載されている場合はそのまま使用し、記載がなければ独自に生成して入力しないでください。+、/、=を含むBase64文字列は完全な形でコピーします。URLエンコードしたり、末尾の=を不要な記号とみなして削除したりしないでください。

AddressとEndpointは別の階層

Addressはトンネル内で自分の端末に割り当てられるアドレスで、通常はCIDRプレフィックス長を伴います。たとえば10.66.0.2/32はIPv4インターフェースアドレスを示します。デュアルスタック設定では、fd00:66::2/128のようなIPv6アドレスが指定されることもあります。これらは書式の例であり、サービス側が実際に割り当てた値の代わりにはなりません。Addressは接続先サーバーのアドレスでも、端末が接続中のWi-Fiのローカルアドレスでもありません。

Address：元の設定どおりに入力し、/32、/128などのプレフィックス長も保持します。画面でIPv4とIPv6の入力欄が分かれている場合は、それぞれ対応する欄に入力してください。1つのアドレス欄に無理にまとめないでください。
Endpoint：接続可能な接続先のドメイン名またはIPアドレスとUDPポートです。たとえば192.0.2.10:51820は書式を示すための例であり、接続先ではありません。
ポートの入力：画面でAddressとPortが別々に表示される場合、サーバーアドレス欄にポートを含めず、Port欄に入力します。例でよく見かける51820に置き換えず、元の設定に記載されたポートを使用してください。
IPv6 Endpoint：標準形式でポートを含むIPv6アドレスを記述する場合は、たとえば[2001:db8::10]:51820のように角括弧で囲みます。画面の入力欄に分ける場合は、アドレス欄の書式に従ってください。

標準設定にはAllowedIPsが含まれることもあります。これはWireGuardのPeerに関連付けるアドレス範囲を示し、WireGuardのルーティングや送信元アドレスの確認に使われます。Addressとは別の項目で、Shadowrocketのグローバルなルーティングルールと同じものではありません。編集画面に対応する項目があるかどうかは、実際に表示される内容を確認してください。0.0.0.0/0が記載されていても、Shadowrocketのすべての通信が必ずその設定を経由するとは限りません。

DNSとMTU：名前解決とパケットサイズを分けて確認

DNSはドメイン名をアドレスに変換するもので、鍵の誤りを解消するものではありません。標準的なWireGuard設定ファイルのDNSはクライアントツールが使う設定項目であり、WireGuardのハンドシェイクにおける認証パラメーターではありません。Shadowrocketでは、現在のConfigとSettingsで有効になっているDNS設定も確認してください。元の設定ファイルにDNSアドレスが記載されているだけで、実行時にも必ず使われるとは限りません。

項目	確認すること	確認できる症状
`DNS`	DNSサーバーに到達できるか、トンネル経由でのみアクセスできるのか、Endpointのドメイン名を事前に名前解決できるか。	ドメイン名の名前解決でエラーが出る一方、接続先のIPアドレスが既知なら接続テストに応答することがある。
`MTU`	まずは元の設定を使用する。トンネルでカプセル化した後のパケットサイズが、実際の通信経路で許容される上限を超えていないか。	小さなリクエストは成功するが、大きな応答やアップロードが止まる。一部のWebページの読み込みが長時間続く。
`PersistentKeepalive`	元の設定で定期的なKeepalive送信が必要か、現在のネットワークでNATマッピングがタイムアウトしていないか。	長時間使わなかった後の最初のアクセスに失敗し、再接続すると一時的に復旧する。

MTUの単位はバイトです。1420はよく使われる目安ですが、すべてのネットワークで最適な固定値ではありません。元の設定にMTUが指定されている場合は、まずその値で確認します。「大きなリクエストだけ止まり、小さなリクエストは正常」といった症状が再現する場合に限り、一度に変更する項目を1つに絞って試してください。たとえば1420から1380に下げ、同じページまたは同じアップロードを再テストして結果を記録します。改善しなければ元の値に戻し、DNSやルールを同時に変更しないでください。

元の設定にあるPersistentKeepalive = 25は、Keepaliveを25秒間隔で送信することを示します。タイムアウト時間や再試行回数ではありません。Keepaliveが必要かどうかはネットワークとサービスの設定によります。正しい鍵、Endpoint、利用可能なUDP経路の代わりにはなりません。

Homeで設定し、段階的に検証する

Homeでは接続項目、Configではルール設定、Settingsではアプリの設定を管理します。WireGuardパラメーターの入力とルール設定の読み込みは別の作業です。前者は接続方法を設定し、後者はどの通信にその接続を使うかを決めます。画面によって項目の表示方法が異なる場合があるため、標準設定の項目と画面上の項目は、一覧の位置ではなく意味を照らし合わせてください。

元の設定情報を用意する

利用中のサービスから提供された元の設定を保管し、InterfaceとPeerが同じ端末の設定に属していることを確認します。テスト後に元へ戻せるよう、現在のGlobal Routingの状態も記録してください。
種類を選択する

Home → 右上の「+」→ Type → WireGuardの順に開きます。すでに設定項目がある場合は、Homeからその編集画面を開いてください。内容が似た項目を複数作成する必要はありません。
各項目を対応させる

EndpointをサーバーアドレスとPortに、Interface.PrivateKeyをPrivate Keyに、Peer.PublicKeyをPublic Keyに対応させます。Address、Preshared Key、MTUは、元の設定と編集画面の項目を一つずつ照合してから保存してください。
ルールの影響を切り分ける

Homeに戻り、保存したWireGuard項目を選択します。一時的にGlobal Routing → Proxyに設定し、接続をオンにして、アクセス可能だと確認できているHTTPSページをテストしてください。Configのルールによる影響を抑えて確認できますが、DNSやほかの有効な設定も確認が必要です。
通常の設定に戻す

基本的なアクセスを確認できたら、元のGlobal Routingに戻して同じ接続先を再テストします。Settings → On Demandを有効にしている場合、調査中は一時的に自動接続をオフにすると、手動で切断した後に再接続されるのを防げます。テスト後は元の状態に戻してください。

接続スイッチがオンになっていることは、端末上で接続処理が始まったことを示すだけで、接続先とのWireGuardハンドシェイク完了を証明するものではありません。遅延テストに数値が表示されても、Webページへのアクセスを確認したことにはなりません。テスト対象や方法、実際の通信経路が異なる場合があるためです。ドメイン名の名前解決結果、接続先へのアクセス結果、利用可能な接続ログをあわせて確認してください。

Global Routingが検証結果に与える影響

以下ではテスト結果の違いを説明するため、Shadowrocket内の3種類のルーティング設定を比較します。Global RoutingにはSceneが表示される場合もありますが、この記事では切り分けテストの基準として扱いません。推奨するConfigは、確認済みのルールを日常利用することを指し、任意の設定ファイルがそのまま使えるという意味ではありません。

Config

推奨

現在のConfigのルールとポリシーに従って通信を処理します。先に一致したルールが結果を決めるため、WireGuard項目が使えても、すべてのドメインがその接続を使うとは限りません。

適した用途：基本的な接続確認後の日常的なルールによる振り分け

Proxy

通信をプロキシとして処理し、通常のルールによる振り分けの影響を一時的に抑えて確認できます。テスト前に、選択中の接続が確認対象のWireGuard項目であることを確かめてください。

適した用途：設定後の短時間の切り分けテスト

Direct

接続先へ直接接続します。この設定でWebページが開いても、WireGuardの設定が正しいとは証明できません。同じ接続先にProxyでアクセスした結果と区別して記録してください。

適した用途：現在のネットワークから直接接続した場合との比較

Configに戻り、一部の接続先だけ失敗する場合は、ルールの順序と各ルールで実際に選択されるポリシーを確認します。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPアドレスの地理データベースに基づいて照合します。FINALは、それ以前のルールに一致しない通信に最後の処理を適用します。Configでのみ起きるルール照合の問題を解決するために、Private Keyを何度も変更しないでください。

よくある設定ミスと確認手順

Private Keyを入力しても接続できないのはなぜ？

Homeで対象項目の編集画面を開き、Type、Endpointのアドレス、Port、Private Key、接続先のPublic Keyを順番に確認します。次に、接続先に登録された公開鍵が、このPrivate Keyに対応する自分側の公開鍵であることを確認してください。Preshared Keyが指定されている場合は、双方の値も一致している必要があります。秘密鍵の文字数を確認するだけでは不十分です。

AddressにサーバーのIPアドレスをそのまま入力できますか？

そのように置き換えることはできません。Addressはサービス側が割り当てたトンネル内の自分の端末のアドレスで、サーバーのパブリックアドレスはEndpointに入力します。元の設定のInterface.Addressを確認して、プレフィックス長も含めて入力してください。Addressが分からない場合は、利用中のサービスの管理者に確認します。

Wi-Fiでは正常なのに、モバイル通信に切り替えると失敗する場合は？

まず、どちらのネットワークでも同じ項目、同じGlobal Routing、同じテスト対象を使い、テスト条件の違いを除外します。次に、EndpointのIPv4/IPv6への到達性とUDP経路を確認してください。アイドル状態の後だけ問題が起きる場合は、元の設定のPersistentKeepaliveを確認します。大きなリクエストだけ失敗する場合は、MTUだけを個別に検証してください。

サブスクリプションの更新後、手動変更が消えるのはなぜ？

サブスクリプションで管理される項目は、更新時に設定が再適用されることがあります。編集しているのが手動で作成した項目か、サブスクリプションから作成された項目かを確認し、上書きされた項目とサブスクリプションから取得した設定を照合してください。継続して使う設定は、利用中のサービスから提供された元の設定に合わせます。更新のたびに確認せず変更を繰り返すのは避けてください。

MTUを下げれば、読み込みに関する問題はすべて解決しますか？

いいえ。まずProxyで対象にアクセスできるか確認し、次に名前解決が成功しているかを調べます。再現性のある大きなパケットに関する症状がある場合に限り、MTUのテストを続けてください。鍵の不一致、ポートの誤り、DNSサーバーへの接続不可は、MTUを下げても自動的には解決しません。

問題を調査した後は、使用したネットワーク、Global Routing、テスト対象、変更した項目、結果を記録してください。利用中のサービスの管理者に報告する際は、「同じ接続先がProxyでは失敗し、Directでは成功する」「小さなリクエストは成功するが、アップロードが止まる」などの症状を伝えます。鍵や個人設定は必ず伏せてください。設定ファイル全体を公開するより、条件を揃えた比較結果のほうが原因を特定しやすくなります。