接続設定がすでにあり、通信の振り分けを確認したい方や.confを管理したい方に向けた記事です。まずHomeの接続項目とConfigの設定ファイルを区別し、General、Rule、Host、URL Rewriteを順に確認します。読み終えると、設定行がどのセクションに属するか、期待どおりに動作しない理由、元の設定を残しながら項目ごとに検証する方法がわかります。
1. .conf・接続項目・現在の動作状態を区別する
Shadowrocketの.confは設定内容を整理するファイルで、接続アカウントそのものではありません。Homeの接続項目にはサーバーアドレス、ポート、認証情報などが保存されます。ConfigのファイルではDNS、ルール、ホスト名のマッピング、リクエストの書き換えなどを設定します。Ruleの一部だけを入手しても、利用可能な接続サービスが自動的に用意されるわけではありません。
確認を始める前に、使用中のファイルとHome → Global Routingの選択状態を確認してください。Configを選択している場合に、この記事のRuleによる振り分けを確認できます。ProxyとDirectでは全体の処理方法が異なるため、その結果だけで特定のRuleが正しいとは判断できません。Sceneは状況に応じて選択する機能です。問題の切り分けでは、該当Sceneの設定も確認してください。固定のRuleセットとして扱うことはできません。
角括弧でセクションを宣言し、次のセクション名が現れるまで後続の行がそのセクションに属します。Generalではキーと値の組み合わせ、Ruleではカンマ区切りのフィールドがよく使われます。この2つの書式を混同しないでください。以下は手動で確認する際の手順であり、すべての通信が4つのセクションの記述順どおりに処理されるという意味ではありません。
2. General：まずDNS、次にその他の全般設定
[General]内のキー名によって全般設定の意味が決まるため、等号の右側の値だけを見ても判断できません。ドメインに接続できない場合は、まずdns-serverを確認し、「名前解決の失敗」と「名前解決は成功したが接続に失敗した」状態を区別します。前者では名前解決の経路を確認し、後者ではルーティング、接続先ポート、既存の接続項目の認証設定なども確認します。
[General]
dns-server = systemここでのsystemは、システムが提供するDNS設定を使うという意味です。systemという名前のサーバーアドレスを指すものでも、リクエストが必ず直接接続されることを示すものでもありません。実際の名前解決結果は、現在のネットワーク、キャッシュ、その他のDNS関連設定にも左右されます。元のファイルに追加のDNS設定がある場合は、前後の設定も含めて確認してください。この1行だけで名前解決全体を判断しないでください。
- Configで使用中のファイルを開き、
dns-serverの元の値を記録して、復元用のコピーを残します。 - 同じテスト用ドメインで問題を再現し、接続中のネットワークがWi-Fiかモバイル通信かを記録します。
- DNS設定を1項目だけ変更して保存し、変更後のファイルが使用中であることを確認してから、リクエストを再実行します。
- 解決しない場合は、接続先IPを取得できたか、想定したRuleにマッチしたか、接続先への接続が確立したかをそれぞれ確認します。
3. Rule：具体的な条件を先に置き、最後にFINALを残す
[Rule]では、リクエストにマッチするポリシーを指定します。通常、ルールは上から順に評価され、最初にマッチした有効なルールで処理方法が決まるため、具体的なルールを範囲の広いルールより前に置きます。以下は読み方を説明する例です。example.comは例示用ドメインで、PROXYを使うにはユーザーが有効な接続設定を用意している必要があります。この例だけで使える完全な設定にはなりません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYドメインとIPアドレス範囲のマッチ
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.168.0.0/16,DIRECT,no-resolve
- no-resolve
- このIPルールのためにドメイン名の名前解決を行わない
まずドメイン名の条件とIPアドレスの条件を区別し、ルールにマッチする可能性があるか確認します。
地域判定とフォールバック
- GEOIP
- CN,DIRECT
- FINAL
- PROXY
- Global Routing
- この記事のルールを確認するときはConfigを選択
地域判定はIPデータに基づき、FINALはそれまでのルールにマッチしなかったリクエストを処理します。
DOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメイン（例：www.example.com）にマッチしますが、任意の文字列に対する部分一致ではありません。特定のポリシーを適用したいドメインのルールは、GEOIPなど範囲の広い判定より前に置き、別のルールに先に処理されないようにします。
IP-CIDRはIPアドレス範囲にマッチします。例の192.168.0.0/16は、該当するプライベートアドレス範囲を示します。no-resolveの効果は、そのルールでの名前解決の動作に限られ、アプリ全体のDNSを無効にするものではありません。GEOIP,CN,DIRECTは接続先IPの地域データに基づく判定であり、「中国語のWebサイトはすべて直接接続する」という意味ではありません。
結論：ルールが効かない場合は、まずFINALの位置を確認
FINALをルールの末尾に置き、対象のルールがFINALより前にあること、Global RoutingがConfigになっていることを確認します。この3点を確認してからマッチ条件を変更し、動作モードの問題を構文の問題と取り違えないようにします。
4. Host：名前解決を変更する設定であり、接続ポリシーの代わりにはならない
[Host]では、ドメイン名とIPアドレスの対応を明示的に指定します。Hostが「この名前に対応するアドレス」を設定するのに対し、Ruleは「このリクエストをどのポリシーで処理するか」を指定します。両者は置き換えられません。マッピングを追加しても、DIRECTルールやサーバープログラム、到達可能な経路、有効な証明書が自動的に用意されるわけではありません。
[Host]
demo.example.com = 192.0.2.10ここで使う192.0.2.10はドキュメント用の例示アドレスで、テストに使えるサービスではありません。実際にマッピングを設定するのは、自分で管理する対象、またはアドレスが明確にわかっている対象に限ってください。Webページを「開けるように見せる」ために、公開サイトのIPアドレスを安易に固定しないでください。アドレスの変更や分散構成によって、固定したマッピングが機能しなくなることがあります。
- マッピングの範囲：例では
demo.example.comだけを指定しています。他のサブドメインにも同じマッピングが適用されるとは限りません。 - HTTPSの検証：アクセス時に使うホスト名は元のドメイン名のままです。接続先のサービスは、その名前に適合する証明書を提示する必要があります。IPアドレスをマッピングしても証明書の要件はなくなりません。
- 確認方法：該当するマッピングを削除するか元に戻し、接続を再確立して結果を比較します。以前の接続を再利用すると、誤った判断につながることがあります。
- マッチ関係：対象のリクエストが実際にどのRuleにマッチしたか確認してください。マッピング後のIPアドレスと最終的なポリシーを同一視しないでください。
5. URL Rewrite：マッチ範囲を絞ってからリダイレクトを検証
[URL Rewrite]では、パターンに一致するリクエストURLに対応した処理を実行します。ドメイン名にIPアドレスを割り当てる機能ではありません。ここではHTTPの一時リダイレクトを例に、「マッチ式」「置換先」「アクション」の3要素を説明します。構文を読むための例であり、普段使う設定に追加する必要はありません。
[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302式の先頭にある^と末尾の$でマッチ範囲全体を指定し、\.はドメイン名のピリオドを文字として表します。この例がマッチするのはhttp://example.com/oldだけです。HTTPS、他のサブドメイン、クエリパラメーター付きのURLには自動的に適用されません。末尾の302は一時リダイレクトを意味し、その後もアクセスが続くかどうかはリクエスト元の処理によります。
- 最初にマッチする完全なURLを1つ決め、次にマッチしないURL（例：
http://example.com/older）を1つ用意します。 - ドメインとパスを明確に指定し、広すぎる式がログイン、決済、APIリクエストに影響しないようにします。
- 置換先が元の式にも再びマッチしないか確認してください。該当する場合、リダイレクトがループする可能性があります。
- 検証時は、最終的にページが表示されたかだけでなく、リダイレクトのステータスと遷移先アドレスも確認します。
6. インポートと更新：接続元とファイル元を区別する
接続用サブスクリプションの更新と.confの更新は別の操作です。この記事では、ユーザーが自身のサービスプロバイダーとサブスクリプションをすでに利用していることを前提としています。サブスクリプションはHomeの接続項目を管理し、設定ファイルはConfigのルールやその他の動作を管理します。サブスクリプションの更新に成功しても、新しいRuleに切り替わったとは限りません。リモート設定を更新すると、ファイルに直接加えたローカル変更が上書きされる場合もあります。
- インポート前：Homeで現在選択中の接続項目を記録し、Configの既存ファイルをコピーして、Home → Global Routingの選択状態も記録します。
- 内容を確認：ファイルの拡張子だけで判断せず、
[General]や[Rule]などの設定セクションが実際に含まれているか確認します。 - ファイルを使用：Configでインポートしたファイルが選択され、使用中になっていることを確認します。ファイルを保存しただけで有効な設定に切り替えていない場合、テストでは古いルールが使われている可能性があります。
- 更新後：カスタムRule、Host、URL Rewriteが残っているか確認し、同じ対象にリクエストを再実行します。
自動接続の動作はSettings → On Demandで別途確認してください。On Demandは特定の条件で接続を開始するかどうかを決める機能で、Ruleによる対象のマッチングを置き換えるものではありません。手動で切断した後に再接続される場合は、FINALを何度も削除するのではなく、まず起動条件を確認します。切り分けのために元の設定を記録し、按需接続を一時的に無効にして手動接続をテストした後、設定を元に戻してください。
設定を共有する前に、Ruleだけでなくすべての行を確認してください。サブスクリプションURL内のtoken、接続認証情報、証明書の秘密鍵は公開しないでください。当サイトでは接続先やサブスクリプションの提供、販売、推奨は行っていません。記事中のドメイン、アドレス、ルールは、書式と確認方法の説明にのみ使用しています。
7. よくある質問：症状から該当するセクションを特定
Ruleを変更したのに、アクセス方法が変わらないのはなぜ？
まずConfigで、変更したばかりのファイルが使用中か確認します。次にHome → Global RoutingでConfigが選択されていることを確認してください。その後、上位のルールが先にマッチしていないかを確認し、既存の接続を切断してからリクエストを再実行します。すでに確立した接続は、ルールを編集しただけでは必ずしも再評価されません。
Hostを追加したらHTTPSでエラーになるのはなぜ？
まずマッピング先のIPアドレスが正しいか、またサーバーが元のドメイン名に対応するHTTPSサービスを提供しているか確認してください。Hostが変更するのは名前のマッピングだけで、証明書は変更されません。元のマッピングに戻してリクエストを再実行し、結果を比較してください。原因の特定に証明書エラーの無視を使わないでください。
リモート設定を更新したら、カスタムルールが消えたのはなぜ？
まず更新後のファイルとバックアップを比較し、ローカルの変更がリモートの内容で上書きされたか確認してください。管理が必要なルールは別のコピーに保存し、順序とポリシーを確認してから使用します。バックアップを取らずに、手動編集したリモートファイルを何度も更新しないでください。
4つのセクションをコピーすれば接続できますか？
いいえ。この記事の例にはサーバーアドレス、アカウント、認証パラメーターがなく、利用可能なサービスも構成されていません。まずユーザー自身が利用できる有効な接続設定を用意し、そのうえで振り分けをテストしてください。接続先に接続できない場合は、DNS、接続項目、ルールをそれぞれ確認します。セクションを追加するだけでは解決しません。
最終確認では、テスト対象とネットワーク条件を固定します。同じドメイン、同じリクエストパス、同じWi-Fiまたはモバイル通信を使い、一度に変更するのは1項目だけにしてください。「どの設定ファイルを使ったか、どのルールにマッチしたか、どのアドレスに名前解決されたか、接続のどの段階で失敗したか」を説明できれば、その後の切り分けが容易になります。ファイル全体を何度もインポートするのではなく、状況を確認しましょう。