Shadowrocket 設定ガイド

サーバーを1件手動入力

Shadowrocketを開いたら、まずHomeに移動します。下部のSERVERグループからAdd Serverをタップして追加画面を開きます。最初の項目は通常Typeです。既存のサーバー情報に記載されたプロトコルと一致させてください。例としてShadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2があります。プロトコルは項目構成を決める入口であり、ポート番号やサーバー名だけから推測することはできません。

Typeを選択したら、原情報に従ってHost、Port、Password、Methodと、そのプロトコルで必要なその他の項目を順に入力します。Hostにはホスト名またはIPアドレスだけを入力し、説明文は付けません。Portにはポート番号だけを入力します。Password、UUID、Method、TLSなどは、元の大文字・小文字と文字順を維持してください。情報に記載されていない項目は勝手に補わず、そのTypeで本当に必要かを先に確認します。

Type: Shadowsocks
Host: example.com
Port: 443
Password: your-password
Method: 手元の情報に従う

上記は項目の位置を説明するためのもので、接続可能な情報一式ではありません。入力が完了したら、画面の保存操作でHomeに戻ります。新しい項目がSERVERグループに表示されたらタップし、現在のサーバーとして選択します。この時点ではGlobal Routingを急いで変更せず、名前、Type、Host、Portが原情報と一致していることを確認します。

Subscribeから既存の購読をインポート

完全な購読リンクを持っている場合は、サーバーまたは購読管理の入口からSubscribeを選択します。リンクを対応するアドレス欄に完全な状態で貼り付け、必要に応じて識別しやすい名前を入力して保存・更新します。形式の例は次のように記載できます。

https://example.com/sub?token=xxxx

例のドメインとパラメータはリンク構造の説明だけを目的としています。実際にはユーザー自身が持つ完全なアドレスを使用してください。貼り付け後は、3点を重点的に確認します。先頭に正しいhttps://が含まれているか、途中に改行による空白が入っていないか、末尾のパラメータがチャットツールで欠落していないかを確認します。更新に成功すると、HomeのSERVERグループに購読から返された項目が表示されます。更新に失敗した場合は元のリンクを保持し、同名のSubscribe項目を連続して作成しないでください。

購読はサーバー情報をまとめて管理する方法の1つです。サービス提供元が内容を更新した場合は、既存のSubscribe項目で更新し、リンクを何度も貼り付けて重複リストを作らないようにします。購読から生成された項目を手動で変更すると、次回の更新時に購読内容で上書きされる場合もあります。個別に調整したサーバーを残したい場合は、その項目が購読で管理されているかを確認してから変更方法を決めてください。

Homeに戻り、Global Routingをタップします。日本語の説明では、3つのモードをConfig、Proxy、Directと表記します。これらはトラフィックがShadowrocketに入った後の処理方法を決めるもので、サーバーが利用可能かどうかとは別のものです。

Config：ルールに従って順に判定

Configは日常的なルール分流に適しています。リクエストは現在の設定ファイルにあるRuleの並び順に従って上から順に照合され、最初に適用されたルールのポリシーが使われます。代表的なキーワードにはDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6、USER-AGENTがあります。処理結果は通常PROXY、DIRECT、REJECTのいずれかです。具体的な結果はキーワード名ではなく、設定ファイルの内容によって決まります。

Configを開いたら、まず現在選択されている設定ファイルを確認し、次にRuleを確認します。より具体的なドメインまたはアドレスのルールは通常前方に置き、より広い範囲のルールは後方に置きます。これまで一致しなかったリクエストは最後にFINALで処理されます。広範囲のルールが早い位置にあると、後続のより具体的な項目は照合されません。

Proxy：現在のサーバーに一括して処理させる

Proxyは、Shadowrocketに入るトラフィックを現在選択しているサーバーに一括して処理させます。短時間の比較テストに適しています。Configで対象に期待どおりアクセスできず、Proxyでアクセスできる場合は、問題がルール照合、ポリシー名、Configの選択にある可能性が高くなります。Proxyでも失敗する場合は、サーバー情報、接続性、DNS、ローカルネットワークを優先して確認します。

Direct：プロキシサーバーを経由しない

Directでは現在のネットワークを直接使用します。比較による切り分けにも利用できます。たとえばDirectでは正常でProxyでは失敗する場合、サーバー接続とサーバー項目を確認します。Directでも異常がある場合は、現在のWi-Fi、モバイルネットワーク、DNS、対象側に原因がある可能性があります。Directはトラブルシューティング用のモードであり、サーバーの検証が完了したことを意味しません。

初回設定では、まずProxyでサーバー接続の基準を確認し、その後Configに戻って分流結果を確認することをおすすめします。Global Routingの切り替えを恒久的な解決策にしないでください。ProxyではアクセスできてConfigではできない場合、どのルールに一致したかの違いを特定します。Configが正常に動作して初めて、ルール層の設定が完了したと判断できます。

DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

このルールは、順番に照合する書き方を示す例です。最初のルールが指定したドメインのサフィックスを優先して処理し、ローカルネットワークのアドレスはIP-CIDRで直接接続し、一致しなかったリクエストは最後にFINALへ進みます。実際の設定はユーザー自身の利用目的に合わせて整理してください。ルールの優先順位、DNS、複雑な障害について体系的に確認する場合は、トラブルシューティング文書も参照してください。

接続前にHomeへ戻り、上から順に簡単な確認を行います。SERVERグループで対象サーバーが選択され、Global Routingに想定したモードが表示され、現在のConfigとルールも確認済みであることを確認します。その後、上部の接続スイッチをオンにします。初回接続時にはシステムからVPN構成の許可が求められます。システムの手順に従って許可すると、Shadowrocketが本体のネットワークトンネルを作成できるようになります。

スイッチをオンにすると、Home上部の状態がNot ConnectedからConnectedに変わります。状態の変化は本体のトンネルが確立されたことを示しますが、遠隔サーバーが利用可能であることや、すべてのリクエストが期待するルールに一致したことを単独で証明するものではありません。Connectedになった後も、Connectivity Testと実際のリクエストによる確認を続けてください。

状態が一時的に変化した後すぐNot Connectedに戻る場合、スイッチを連続して素早くタップしないでください。数秒待ってから、現在のサーバーが選択されているか、項目が不足していないか、システムがVPN構成の作成を許可しているかを確認します。システム内で他のネットワーク状態が切り替わっている場合は、Wi-Fiまたはモバイルネットワークが安定してから再試行してください。

単一で再現可能なテスト条件を先に作る

初回テストでは、On Demandを同時に有効にしたり、Configを頻繁に切り替えたり、複数のサーバーを連続して変更したりしないでください。1つのネットワーク、1つのサーバー、1つのGlobal Routingモードを固定し、完全な検証を1回終えてから次の項目を変更することをおすすめします。これにより、「スイッチをオンのまま維持できない」「サーバーがタイムアウトする」「ルールの一致が想定と異なる」を分けて確認できます。

iPadでは、横向き表示や分割表示によってHomeの項目配置が変わる場合がありますが、操作の流れは同じです。サーバーを選び、Global Routingを確認し、接続をオンにしてから検証します。Mac、Apple TV、Apple Visionの互換性は同じApp Store製品ページで確認できます。システム要件はApp Storeページの記載に従います。本ページはiPhoneとiPadを中心に説明します。

検証は2段階に分けます。第1段階では選択したサーバーが有効な接続を確立できるかを確認し、第2段階では実際のリクエストがGlobal RoutingとConfigのルールに従って処理されるかを確認します。スイッチの状態だけでは遠隔サーバーのタイムアウトを見落とし、1回のウェブアクセスだけではキャッシュ、DNS、ルールの影響を区別しにくいためです。

Connectivity Testを実行

HomeでConnectivity Testをタップし、現在のサーバーの接続テストを実行します。テストが完了すれば、サーバー情報と現在のネットワークに少なくとも基本的な通信条件があることを示します。timeoutや結果が出ない状態が続く場合は、Add Serverに戻り、Type、Host、Port、Password、Method、およびプロトコルに必要な項目を確認します。購読から生成された項目は、先に元のSubscribeを更新してから、サーバーを選び直してテストします。

Connectivity Testの結果は、接続性を判断する手がかりにすぎません。ルール検証の代わりにはならず、すべての対象が同じ経路を使うことも示しません。テストに成功したら現在の設定を保持し、識別しやすい実際のアクセスを1回行って、リクエスト記録を確認します。

Dataまたは接続記録で結果を確認

Data、またはアプリ内で接続記録を確認できる画面を開き、表示を整理してから対象へもう一度アクセスします。新しく発生したリクエストを見つけ、ドメイン、対象アドレス、ポリシー、ルール情報を確認します。Configモードでは、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのどれに一致したか、最終結果がPROXY、DIRECT、REJECTのどれかを重点的に確認します。

リクエストが誤ったルールに一致した場合、まず順序を確認し、サーバーを先に変更しないでください。ルールは上から順に処理され、先に一致した項目で今回の判定が終了します。たとえば範囲の広いDOMAIN-SUFFIXルールが具体的なDOMAINルールより前にあると、後者は使われない可能性があります。変更後はConfigを保存し、Homeに戻ってそのConfigが選択されたままであることを確認してから、リクエストをもう一度発生させます。

3つのモードで最小限の比較を行う

1. Directの基準：短時間だけDirectに切り替え、現在のローカルネットワークで基本的なアクセスが完了するか確認します。
2. Proxyの基準：Proxyに切り替え、現在選択しているサーバーがアクセスを処理できるか確認します。
3. Configの検証：Configに戻し、Dataで対象リクエストのルールとポリシー結果を確認します。

Directは正常でProxyが失敗する場合は、サーバー情報とConnectivity Testを優先して確認します。Proxyは正常でConfigが失敗する場合は、現在の設定ファイル、Ruleの順序、ポリシー参照を優先して確認します。3つすべてのモードで失敗する場合は、ローカルネットワーク、DNS、対象の状態を先に確認します。比較の各回では同じサーバーと同じ対象を使い、新しい変数を増やさないでください。

トラブルシューティングは「入力情報—サーバー接続—本体の接続—Global Routing—Configルール—DNSとネットワーク」の順に行います。一度に変更するのは1つの層だけにし、変更後は同じテストを繰り返します。サーバー、ルール、DNSを同時に変更すると、正常に戻っても本当の原因を判断できません。

Subscribeの更新に失敗する

まずリンクが完全で、空白や改行がなく、先頭のプロトコルが元のアドレスと一致し、末尾のパラメータが欠落していないことを確認します。次にShadowrocketの接続を一時的にオフにし、現在のネットワークからそのアドレスへ正常にアクセスできることを確認してから、元のSubscribeで更新します。問題を隠すために同名の項目を複数作らないでください。重複項目があると、後で選択を誤りやすくなります。

Connectivity Testがタイムアウトする

手動で追加したサーバーは、Type、Host、Port、Password、Method、TLS、プロトコルで必要な追加項目を順に確認します。Subscribeから生成されたサーバーは、先に購読を更新してから対象項目を選び直します。その後、Wi-Fiとモバイルネットワークで1つの変数だけを変えて比較します。特定のネットワークだけで失敗する場合は、そのネットワークのDNS、認証ページ、接続制限を確認します。

Connectedなのにアクセスできない

まずDirectに切り替えてローカルネットワークの基準を確認し、次にProxyでサーバーの基準を確認します。Directは利用できるのにProxyが利用できない場合は、サーバーとConnectivity Testに戻ります。Proxyは利用できるのにConfigが利用できない場合は、現在のConfig、Ruleの順序、ポリシー名、FINALを確認します。状態がConnectedでもDataに新しいリクエストが表示されない場合は、システムのVPN状態がShadowrocketに対応しているか、On Demandが接続開始条件を変えていないかを確認します。

一部の対象だけ結果が想定と異なる

この問題は通常、ルール層にあります。まずDataで該当リクエストの実際のドメインまたはIPを確認し、最初に一致したルールを調べます。ブラウザのアドレスバーだけで判断しないでください。1つのページが複数のドメインへ同時にリクエストする場合があります。特定のドメインにはDOMAINまたはDOMAIN-SUFFIXを使い、キーワード範囲にはDOMAIN-KEYWORDを慎重に使用します。アドレス範囲にはIP-CIDRまたはIP-CIDR6を使用できます。ルールを追加したらConfigを保存し、リクエストを再発生させて確認します。

DNSの名前解決に異常がある

Connectivity Testは完了するのに、ドメインへのアクセスに失敗し、直接アドレスの結果が異なる場合はDNSを確認します。まず原因を説明できるDNS設定に戻し、複数の名前解決方式を同時に重ねないようにします。その後、Direct、Proxy、Configで同じドメインをそれぞれテストし、Dataに名前解決後の接続が表示されるか確認します。複雑なHosts、URL Rewrite、HTTPS Decryptionの設定も結果を変える可能性があります。トラブルシューティングでは、それらが現在の問題に関係しているかを先に確認してください。

On Demandによって状態が繰り返し変わる

On Demandはネットワーク条件に応じて接続または切断を実行します。初回設定とトラブルシューティング中は、まずOn Demandをオフにして手動で安定した接続を1回確立することをおすすめします。基本手順の確認後、Settingsに戻って実行条件を設定します。Wi-Fiを切り替えた直後、特定のネットワークから離れた後、またはデバイスの復帰後に状態が変化する場合は、Homeのスイッチを繰り返しタップするだけでなく、On Demandの条件も確認してください。

変更しても原因を判断できない

SettingsのDiagnosticsと関連するテスト項目を使って状況を記録します。現在のネットワーク、サーバー名、Global Routing、Config、Connectivity Testの結果、具体的な失敗時刻を残してください。診断情報を共有する前に、個人の接続情報が含まれていないか確認します。ネットワークに接続できない、ノードのタイムアウト、購読失敗、速度低下、DNS、バッテリー消費、iPad固有の手順については、Shadowrocketトラブルシューティング大全で章ごとに確認できます。