ShadowrocketのSettings設定ガイド、接続状況に合わせた値の確認方法

まず設定が属する階層を確認

Shadowrocketの接続結果はSettingsだけで決まるわけではありません。Homeで選択したサーバーが接続先を決め、Global Routingがルールに従って接続先を振り分けます。Configで現在使用中のファイルがルールや一部のネットワーク設定を提供し、Settingsにはテスト、接続補助、アプリの環境設定などが保存されます。さらに、システムのVPN許可やネットワーク環境、バックグラウンド処理も関係します。問題を調べる際は各階層を分けて考え、サーバーの認証情報が無効なのにDNSを何度も変更したり、DirectモードのままPROXYルールの正しさを判断したりしないようにしてください。

「既定値」は特定の環境における初期値、「現在値」は画面に表示されている値、「適用値」は実際の接続で使われている値です。これらは一致しないことがあります。Configを読み込むと、ファイル内の名前解決設定が実際の経路を変える場合があります。ファイルを編集しても、そのファイルを選択していなければ今回の接続には反映されません。本ページの推奨事項を確認する際は、まず現在のプラットフォームに該当項目があるかを確認し、アプリ内の説明、選択中のConfig、実行中の接続を照らし合わせてください。古い画面の画像だけで判断しないようにしましょう。

元に戻せるよう変更前の状態を記録する

作業前に、現在のネットワークの種類、サーバー名、Global Routingのモード、Configファイル名、変更する項目を記録します。既存の設定はコピーを残し、サブスクリプションから生成されたファイルと手動で管理するファイルは別の名前にしてください。用途を名前に含めるのは構いませんが、アカウント情報や完全なアドレスは書かないでください。エクスポート内容にサーバーのパスワード、サブスクリプションの情報、個人を特定できる情報が含まれる場合は、自分で管理できる場所にだけ保存します。相談用のスクリーンショットでは該当箇所を隠し、通常のクエリパラメーターに見えるアドレス内の認証情報も見落とさないでください。

一度に変更するのは一項目だけにし、確認できる目標を決めます。たとえば「DNS変更後、同じドメイン名を名前解決できる」は「ネットワークを改善する」より検証しやすく、「Wi-Fiに戻ったとき自動接続しない」は「バックグラウンド動作を止める」より明確です。以前アクセスできた対象を比較用に一つ選び、問題のある対象も一つ選んでください。両方にアクセスできない場合は、まずネットワークと接続自体を確認します。問題のある対象だけ失敗する場合は、ルール、名前解決結果、対象サービスを調べ、すぐに全設定をリセットしないでください。

推奨する開始状態と元に戻す条件

正常に使えている設定は基準として残し、項目名が高機能に見えるからという理由だけで有効にする必要はありません。安定した接続を確立できていない場合は、まず手元の設定が求める条件に従い、自動化条件や手動の上書きを増やさないようにします。変更を保存したら、設定に応じて切断・再接続してください。設定画面を開き直すだけでは、ネットワークセッションが再構築された証拠になりません。再テストでは同じネットワーク、同じサーバー、同じ対象を使い、変化が設定によるものか環境によるものかを判断できるようにします。

新たな問題が起きたら、補助設定を重ねるのではなく、直前に変更した項目をまず元に戻します。元に戻しても症状が続く場合は、古い接続、システムのDNSキャッシュ、アプリのキャッシュ、ネットワーク切り替えの影響を確認してから、新しい接続を確立してください。復旧の範囲も明確にします。テスト結果を取り戻すために、すべてのサーバーを消したり、サブスクリプションを削除したり、クライアントを再インストールしたりしないでください。インポートから初回接続までの手順を確認する場合は、チュートリアルの操作手順を参照し、体系的なトラブルシューティングと初回利用を分けて進めてください。

システムDNS・カスタムDNS・DNS over HTTPS

DNSはドメイン名を接続に必要なアドレスへ変換する仕組みです。プロキシサーバーの代わりにはならず、誤ったプロトコル設定も修正しません。システムDNSは通常、現在のネットワークが提供する名前解決設定に従うため、ネットワーク本来の挙動を確認する出発点になります。カスタムDNSでは名前解決サービスを指定しますが、利用できるかどうかは現在のネットワークや設定に左右されます。DNS over HTTPSはHTTPS経由で問い合わせる方式で、接続先の指定、接続の確立、証明書の検証も必要です。方式を選ぶ前に、問題が名前解決の段階で起きていることを確認してください。ウェブページが開かないからといって、すべてのDNS設定を一度に変更するのは避けましょう。

既定の状態は、現在のクライアントと選択中のConfigの両方で確認してください。入力欄が空だからといって「名前解決しない」とは限りません。空欄はシステム設定の継承、Configの値の使用、クライアント内蔵の動作を意味する場合があります。具体的には項目の説明に従ってください。Configの該当箇所ですでに名前解決の設定が指定されている場合は、まずコピーを残し、ファイル側を変更するかアプリ側で調整するかを決めます。同じ目的の設定元は一つに定め、画面上の値とファイルの値が食い違って、設定が保存されていないと誤解しないようにします。

推奨値はネットワーク環境に応じて選ぶ

通常のトラブルシューティングでは、動作している名前解決方式をまず維持してください。カスタム設定が必要な場合は、利用できることを確認済みで、選択した項目の書式に合うアドレスだけを入力します。従来型のDNSアドレスとHTTPSの接続先は、自由に置き換えられる文字列ではありません。IPアドレスのみを受け付ける欄に完全なURLを貼り付けないでください。複数の値を指定できる場合も、カンマ、空白、改行のどれで区切るかを推測せず、アプリの説明に従います。名前解決先は一つずつ追加し、名前解決とアクセスの両方を確認してから、予備の設定が必要か検討してください。

社内ネットワークなどのドメイン名は、よくある例外です。プリンター、社内サービス、ルーターの管理用名称は、現在のネットワークが提供するDNSだけで解決できる場合があります。すべてを外部の名前解決方式に切り替えた結果、一般のウェブサイトには接続できても社内の名前が使えなくなったとしても、プロキシサーバーの故障とは限りません。反対に、自宅で使えるDNSがホテルや職場のネットワークでは接続できない場合もあります。ネットワークを切り替えたら名前解決の経路を再確認し、必要に応じて社内向けの処理を残してください。一つのネットワークで有効だった設定を、すべての環境に共通する推奨値とみなさないようにしましょう。

名前解決の成功はアクセス成功を意味しない

動作確認では、まず同じドメイン名からアドレスを取得できるかを見ます。次にリクエストが想定したポリシーに一致しているかを確認し、最後に対象サービスが応答を返すかを確かめます。ドメインルールは接続前に名前で一致する場合がありますが、IP系ルールはアドレス情報に依存することがあります。この2種類の結果を混同しないでください。IPv6アドレスを取得できても、現在のネットワークやサーバー経路でIPv6接続が確立できるとは限りません。断続的に失敗する場合は、返されたアドレスの種類、適用されたポリシー、実際のエラーを別々に記録し、一度の再試行が成功しただけでDNSの問題が解決したと判断しないでください。

変更前の結果が、システム、ブラウザー、アプリのキャッシュに一時的に残る場合があります。まず接続を作り直して対象へのリクエストを新たに行い、必要であれば対象アプリも終了して起動し直して、古いセッションの再利用を避けます。名前解決先を素早く何度も切り替えて比較するのはやめましょう。キャッシュ、ハンドシェイク、ネットワークの揺らぎが混在します。より詳しい経路の比較はDNS設定の技術ノートをご覧ください。元に戻す場合は、元の名前解決方式と設定元を復元して社内向けの名前も再テストし、一般のアクセスが戻るだけでなくローカルサービスにも影響がないことを確認します。

接続するタイミングを決める機能で、適用するルールは決めない

On Demandはシステムのネットワーク条件に応じて接続を開始する機能で、Global Routingとは役割が異なります。前者は「いつ接続を確立するか」、後者は「接続後に対象をどのポリシーで処理するか」を決めます。On Demandを有効にしても、サーバー情報が自動で補われたり、Configの不足ルールが追加されたりすることはありません。初めて使う場合は、先に手動で安定した接続を確認し、その後で自動化条件を設定してください。手動接続自体が失敗する状態では、自動接続も同じ失敗を繰り返し、状況の確認が難しくなります。

既定のスイッチ状態や既存のシステム設定は、端末の実際の表示で確認してください。「常にオン」を一律の推奨にはしません。手動で接続を管理したい場合は、まず手動接続のままにすると基準を作りやすくなります。ネットワーク条件に応じた接続が必要な場合は、現在の画面で利用できる条件を一つずつ設定してください。使用中のプラットフォームにない条件を他の端末の手順から転記したり、システムの自動接続許可とクライアント内のスイッチを同じ設定とみなしたりしないでください。

条件を一つずつ検証できるようにする

設定前に、「指定したネットワークでは手動接続を維持し、それ以外では条件に応じて接続する」のように、要件を明確に書き出します。Wi-Fi名で条件を設定できる場合は、名称を正確に確認してください。似た名称、同名のネットワーク、非公開ネットワークの影響にも注意します。ネットワーク名が同じでも、安全性まで同じとは限りません。ネットワーク名による照合は接続条件であり、認証の仕組みではありません。複数条件を追加する場合は、現在の画面で優先順位や一致順の説明を読み、リスト上の見た目の位置だけで実行順を判断しないでください。

「一つのネットワーク、一つの条件、一回の切り替え」の手順で確認します。まず現在のWi-Fiで動作を確認し、モバイル通信に切り替え、最後に元のWi-Fiへ戻して、システムのVPN状態とアプリ内の接続状態をそれぞれ記録してください。テスト中は同じサーバーとConfigを使い、サブスクリプションの更新やサーバー選択の変更が重ならないようにします。システムの状態アイコンが示すのはトンネル関連の状態であり、特定の対象に接続できる証明ではありません。条件が発動した後に明確なリクエストを行い、接続の成否と想定したポリシーが適用されたかを確認してください。

認証が必要なネットワーク、スリープ、手動切断

ホテル、駅、ゲスト用Wi-Fiでは、認証ページを先に開く必要がある場合があります。ネットワーク名が条件に一致しても、インターネット接続が完了していないため、自動接続がタイムアウトすることがあります。まずネットワークの認証を済ませてから、設定した条件をテストしてください。認証ページが開かないからといって、サーバーの故障と判断しないでください。認証のため一時的にOn Demandを無効にする場合は、元の状態を記録し、認証後に戻します。ネットワークが通常の状態から制限付きに変わった場合も、「システムが接続を開始しなかった」のか、「接続を開始したが失敗した」のかを区別してください。

端末の画面ロック、アプリのバックグラウンド移行、省電力状態によって、動作を観察できるタイミングが変わることがあります。「アプリを終了して数秒間変化がない」だけで設定ミスと判断したり、一定のバックグラウンド接続時間を保証したりしないでください。手動切断後に再接続するかどうかは、現在のシステム条件と設定によります。切断直後に接続が戻る場合は、VPN設定を何度も削除する前にOn Demandを確認してください。一時的に切断した状態を保つ必要がある場合は、自動接続条件を先に無効にしてシステム状態を確認します。条件に一致した再接続を、スイッチの故障と誤解しないようにしてください。

元に戻すときは、追加した条件をまず無効にし、動作を説明できる手動接続の流れに戻してから、元のサーバーとConfigを確認します。システムのネットワーク設定をすべて削除しないでください。他の用途の設定まで消えるおそれがあります。手動接続は正常で、特定のネットワーク切り替えだけに問題がある場合は、切り替え前後の記録を残し、同じ条件で再現するか確かめます。互いに上書きし合う多数の条件より、安定して再現できる単一条件のほうが長期運用に向いています。

Config・Proxy・Directの3つのモード

Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う、Proxy経由、直接接続の3つのモードです。Configは選択中の設定に沿って対象を処理します。Proxyは対象への通信がProxy経由の場合の挙動を一時的に確認するのに適しています。DirectはProxyを経由しない場合のアクセス状況を確認できます。画面のモード名とルール内の大文字のポリシー語は異なる階層にあるため、どちらにもPROXYやDIRECTが含まれているからといって、互いに置き換えられると考えないでください。DNSやシステムのネットワーク動作は別途確認が必要です。モードを切り替えただけでは、ネットワーク経路全体を把握できません。

既存のルールを通常どおり使う場合は、ルールを追加する前にConfigモードになっているか、正しいファイルが選択されているかを確認してください。現在の既定モードはHomeの表示、ファイルの既定内容は手元のConfigで確認します。Proxyに切り替えたら対象にアクセスできたとしても、2つの経路の挙動が異なることが分かるだけで、ドメインルールの誤りが証明されるわけではありません。名前解決結果、ルールの適用範囲、接続先サービス側の出口制限なども考えられます。テスト後は元のモードに戻し、一時的な診断モードのまま使い続けないようにしてください。

ルールは上から順に評価し、具体的な条件を先に、最終処理を最後に

ルールは通常、上から順に評価されます。具体的な例外を広い条件より前に置き、最終処理を末尾に配置します。DOMAINはドメイン名の完全一致、DOMAIN-SUFFIXはドメインの末尾と関連するサブドメイン、DOMAIN-KEYWORDは名称に含まれるキーワードに一致します。キーワードルールは範囲が広く、意図していない名称まで対象になることがあります。追加する際は、実際のリクエスト記録と照らし合わせてください。IP-CIDR、IP-CIDR6、GEOIPはアドレス範囲や地域情報を対象にするため、ドメインルールと名前が似ているからといって置き換えられるものではありません。

以下はルールの順序を理解するためのShadowrocket .conf形式の例です。接続に必要な設定一式ではなく、サーバー情報も含みません。例のドメインは構文の説明用であり、テスト用サービスではありません。1行目は一致したドメインの末尾をPROXYへ、2行目は指定したプライベートアドレス範囲をDIRECTへ送ります。3行目はGEOIP条件に従ってDIRECTを選び、それ以外のリクエストはFINALでPROXYへ送ります。この最終ポリシーを使うかどうかは、利用者自身の設定目的に応じて決めてください。既存ファイルに例全体をそのまま上書きしないでください。

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

設定更新で手動変更が上書きされないようにする

Subscribeは、利用者がすでにお持ちのサブスクリプションの更新を管理する機能であり、Config内のルールファイルが期待どおりに自動統合されるという意味ではありません。サブスクリプションから生成されたサーバー情報、リモート設定の内容、ローカルで編集した内容をそれぞれ確認してください。更新時に再生成されるファイルへ直接書き込んだ変更は、置き換えられる場合があります。元のファイルとローカルの検証用コピーを残し、まずコピーで動作を確認してください。長期的に維持するルールは、現在のクライアントが対応している方法で管理し、更新後に確認する項目を明確にします。手動編集がどのファイルでも自動的に保持されるとは限りません。

ルールが適用されていないように見える場合は、次の4点を確認します。編集したConfigが選択されているか、Global RoutingがConfigになっているか、想定したドメイン名またはアドレスがリクエストに使われているか、より上位のルールが先に一致していないか。アプリが古い接続を再利用したり、別のドメイン名へリクエストを送ったりすることがあるため、ブラウザーのアドレス欄だけでは一致対象を判断できません。保存して再接続した後、Logで今回のリクエストを見つけてルールと照合してください。まだ分からない場合は、範囲の明確な一時ルールで検証し、終了後に削除します。診断用ルールが長期的に通信経路を変えないようにしてください。

テスト結果だけで接続品質を判断しない

Pingが示す内容は、テスト方法によって異なる場合があります。結果を読む前にSettingsで選択されているテスト方法と対象を確認してください。一覧の時間だけを見て、実際のウェブページ全体の読み込み時間とみなすことはできません。サーバーまでの往復、トランスポート接続の確立、Proxy認証、テスト対象へのアクセスはそれぞれ別の段階です。ある種類のテストに成功しても、応答があったのはそのテストが対象とする段階だけです。別のテストがタイムアウトしても、サーバーがまったく使えないとは限りません。テスト方法と実際のリクエストを合わせて判断してください。

既定のテスト方法、テスト先、タイムアウトは、現在のクライアントに表示される値を確認してください。本ページではプラットフォーム共通の既定値を指定しません。まず利用中のテスト設定を維持し、同じ条件の結果を比較できるようにします。変更が必要な場合は、元の値と変更理由を記録してください。テスト先を指定できる画面では、利用可能で応答が安定しており、そのテスト方法に適した対象を選びます。任意のウェブサイトのトップページを同等のテスト先とみなさないでください。対象側が特定のリクエストを拒否するために、異常な結果になる場合もあります。

タイムアウト・同時実行数・結果の比較

タイムアウトが短すぎると、正常でも時間のかかるハンドシェイクが失敗扱いになります。長すぎると、一連のテストが終わるまでの時間が延びます。まずクライアントの現在値を基準にし、同じネットワークで繰り返し測定した結果を見ながら少しずつ調整してください。最短の数値を目指す必要はありません。モバイル通信への切り替え、端末のスリープ復帰直後、サーバーのドメイン名が未解決の場合は、初回テストに追加の準備時間がかかることがあるため、後続の結果と分けて記録します。項目に単位がある場合は、変更前にミリ秒か秒かを確認し、別の項目の数値をそのままコピーしないでください。

現在のプラットフォームで同時テスト数を設定できる場合、多数のサーバーを一度にテストすると、ネットワークや端末のリソースを使い切ったり、接続先で制限されたりする可能性があります。一台のサーバーを調べる場合は、まず単独でテストし、利用できることが分かっている少数の対象と比較してください。表示順が変わるだけでは故障の証拠になりません。短時間の揺らぎでも順番は変わります。リストを整えるためにテスト先を次々に変更しないでください。前後の測定基準が揃わなくなり、ネットワークが改善したのか、応答の速いテスト先に変わっただけなのか判断できなくなります。

テスト結果と実際のアクセスを結び付けて確認する

有効な検証では、サーバーへのテストが成功したか、接続が確立したか、対象へのリクエストが完了したかを、別々に観察します。まず利用者がすでにお持ちのサーバーでConnectivity Testを実行し、次にそのサーバーを選択して接続し、最後に決めた対象へリクエストを送ってLogを確認してください。3段階すべてで同じネットワークを使い、途中でサブスクリプションを更新しないでください。テストは失敗しても接続と対象リクエストが正常なら、テスト設定の問題として記録します。一覧の状態を直すためだけに、実際に使えている接続を損なわないようにしてください。

ウェブページは開けるのに大容量ファイルの転送が遅い場合、テスト時間だけでは継続的な転送の状態を判断できません。転送速度は対象サービス、ネットワークの混雑、プロトコル設定、接続先の処理能力にも左右されます。また、一度の短い応答時間だけでは長時間接続が安定しているとはいえません。比較する場合は、同じ対象と近い時間帯を使い、上り・下りの速度や切断の状況を記録してください。Hysteria2などのプロトコルの仕組みはHysteria2の技術ノートを参照できますが、プロトコルの解説は特定の接続品質を保証するものではありません。

テスト終了後は、テスト先、タイムアウト、同時実行数を元に戻すか、変更を残す理由を明確にします。相談時には、数値一つだけでなく、テスト方法、ネットワークの種類、症状を再現できるか、実際のアクセスが成功したかを伝えると役立ちます。サブスクリプションの完全なアドレスやサーバーの認証情報は添付しないでください。特定のネットワークでだけ問題が起きる場合は、同じ端末を別のネットワークで使った結果も残します。次に調べるべきなのはネットワーク条件であり、すべてのサーバー情報が無効になったとすぐに判断しないでください。

対象の時間帯を絞ってからエラーを読む

Logは接続の流れを観察できるイベントに分けるためのもので、記録を大量に集めればよいわけではありません。トラブルシューティングを始める前に時刻を記録し、他のアプリの動作をできるだけ減らして、明確な失敗操作を一度だけ再現してから該当記録を確認します。時間帯を絞らないと、バックグラウンド通信、システムの接続確認、対象アプリの再試行が混在しやすくなります。ログにエラーがあっても、それが現在の問題の原因とは限りません。対象、サーバー、時刻、操作が今回の事象と一致しているかを先に確認してください。

ログのスイッチ、レベル、保存方法は、現在のSettingsと各プラットフォームで実際に利用できる機能に従ってください。すべてのプラットフォームに同じログレベルがあるとは限りません。通常時はクライアントの設定を維持するのがおすすめです。詳細な情報が必要な場合だけ一時的に記録範囲を広げ、再現後に元へ戻してください。長時間の記録はストレージや処理の負荷を増やし、機微な情報を含む記録が蓄積されるおそれがあります。ログ設定の変更に再接続が必要な場合は、先に必要な記録を保存してから再接続を確認し、再起動時に問題を説明できる情報を失わないようにします。

名前解決・接続・認証・対象からの応答を分けて確認する

ログは名前解決から読み始め、次に接続先への接続が確立したか、プロトコル認証が完了したかを確認し、最後に対象へのリクエストと応答を追います。名前を解決できない場合はDNSを確認します。接続段階でタイムアウトを繰り返す場合は、現在のネットワークとサーバーへの到達性を確認してください。認証エラーは利用者がお持ちの情報を確認し、対象から内容やステータスが返っている場合は、対象自体の挙動をさらに調べます。すべてのtimeoutを同じ原因として扱わないでください。同じ語が異なる段階に現れる場合があり、対処方法も異なります。

ルールを調べるときは、リクエスト先、適用されたルール、ポリシーをまとめて確認します。ブラウザーでページを開くと、画像、スクリプト、別のドメインにも同時にアクセスする場合があります。アドレス欄の名称だけを検索して判断しないでください。REJECTされたリクエストがあっても、ページ全体の失敗につながるとは限りません。まず必要なリソースかどうかを確認します。ログに表示されていない項目を推測で補わず、再現範囲を絞り、同じ対象へリクエストしてConfig内で一致しそうなルールの位置を確認してください。

Dataの値は集計範囲と合わせて読む

Dataの数値は、現在の画面、集計開始時点、リセット操作と合わせて確認します。サーバー別の表示とアプリ別の表示では分かることが異なります。両方の画面にある数値を、同じ集計条件の値として単純に比較しないでください。少量の送受信はハンドシェイク、再試行、バックグラウンド通信によることがあり、ウェブページの読み込み完了を証明するものではありません。合計値が増えても、特定のルールが適用されたことは分かりません。確認時はサーバーとアプリを固定し、制御できる操作を一定時間行って増分を見ます。直近の障害を過去の累計値から説明しないでください。

値をリセットする必要がある場合は、現在のボタンがどの範囲に適用されるかを確かめ、リセット前の数値を記録します。失敗のたびに統計をすべて消すと、時間との関連が分からなくなります。アプリ別の項目が表示されない場合は、プラットフォームの対応状況、通信が現在の接続を通っているか、選択中の表示を確認してください。存在しないアプリ別の証拠を推測で補わないでください。具体的な数値の読み方はData通信量の解説を参照できます。ログと組み合わせて問題を特定するためのもので、リクエスト記録の代わりにはなりません。

共有する情報は必要最小限にする

ログには完全なドメイン名、リクエストパス、サブスクリプション情報、サーバーアドレス、端末情報、個人を特定できる項目が含まれる場合があります。共有する前に問題に関係する短い部分だけを残し、認証情報や個人を特定できる内容を隠してください。自分のサブスクリプションであっても、完全なアドレスを通常のテキストとして公開しないでください。段階の名称、エラー文、相対時刻があれば、多くの場合は問題を説明できます。診断後はログの範囲を元に戻し、エクスポートしたファイルも必要に応じて削除して、トラブルシューティング用の資料が認証情報のコピーとして長期保存されないようにします。

Widgetは操作の入口であり、ネットワークの検査結果ではない

Widgetを追加するかどうかはシステム画面の利用者設定であり、クライアントで一律に有効になっているとは限りません。まずアプリ内で接続を確認し、必要な操作の入口としてWidgetを追加してください。システムに複数のサイズや操作項目がある場合は、必要なものだけを選べば十分です。接続または切断を操作した後、HomeとシステムのVPN状態を確認します。On Demandの条件が引き続き有効な場合は、手動で切断しても再接続することがあります。Widgetを何度も削除するのではなく、自動接続条件を確認してください。

Widgetを追加するかどうかは、ユーザーがシステム画面で選ぶ項目です。クライアントで一律に有効になっているとは限りません。まずアプリ内で接続を確認してから、必要なショートカットを追加してください。システムが複数のサイズや操作項目に対応している場合は、用途に合わせて選べばよく、すべて配置する必要はありません。接続・切断を操作した後は、HomeとシステムのVPN状態で結果を確認します。On Demandの接続条件が引き続き満たされていると、手動で切断しても再接続することがあります。その場合はWidgetを繰り返し削除するのではなく、自動接続の条件を確認してください。

何を同期するかを先に確認

iCloud同期は、対応するデータを端末間で連携させる機能です。ただし、すべてのSettings、システム権限、Widgetの配置、実行状態まで移行すると考えないでください。現在のクライアントが同期できる内容は、同期画面の説明と実際の結果を確認します。システムのVPN許可は端末ごとの設定です。一方の端末でサーバーを使えても、もう一方で同じ許可が完了しているとは限りません。初回の移行では「設定が表示されたか」と「接続を確立できるか」を別々に確認してください。

同期を有効にする前に、ローカル設定のコピーを保存し、端末で意図したiCloudアカウントを使用しているか、システムがアプリのiCloud利用を許可しているか、ネットワークで同期できるかを確認します。同じアカウントを使っているからといって、同期が完了しているとは限りません。システムの制限、ストレージの状態、バックグラウンド動作の条件によって反映が遅れる場合があります。既定の同期スイッチと対象データは、実際の画面で確認してください。少数の設定をコピーするだけなら、急いですべての同期を有効にする必要はありません。特定のファイルだけが必要な場合は、クライアントが対応するインポート・エクスポート手順を使い、機微な情報を適切に保管してください。

一項目の変更で同期範囲を確認

まず、認証情報を含まず識別しやすい設定名や一般的な環境設定を選び、一方の端末で変更してから、もう一方に反映されるまで待ちます。反映の方向と範囲を確認してから重要なデータを扱ってください。両方の端末で同じファイルを同時に編集すると、どちらが意図したコピーなのか分かりにくくなります。競合や重複が起きた場合は、編集を続けず、両方の内容を保存して比較してから残す方を決めてください。最後に表示された内容を、最新かつ完全なデータだと決めつけないようにしましょう。

別の端末にサーバーが表示されるのに接続できない場合は、同期のオン・オフを繰り返す前に、その端末のネットワークと権限、サーバー情報が揃っているかを確認します。同じデータを使っていても、システムネットワーク、DNS、利用できるプロトコルの違いで結果が変わる場合があります。元に戻す必要がある場合は、保存しておいたローカルコピーを使い、復元内容が他の端末にも再同期されるかを確認してください。削除、置換、同期範囲を理解してから操作し、端末一台のトラブルシューティングを複数端末のデータ変更に広げないようにしましょう。

購入の復元と設定の同期は別に確認

iPhone / iPadで購入を復元する場合は、ダウンロードページの購入済み項目の復元手順に従ってください。iCloudに設定が保存されていても、ストアでの購入状態が復元されているとは限りません。反対に、アプリを復元してもローカルデータがすべて揃うとは限りません。iPhone / iPad版はApp Storeで2.99ドルの買い切り、Mac、Windows、Android、Linux版は無料です。アプリの購入と、利用者がすでにお持ちの接続情報は別のものです。機種変更前に設定を保存し、変更後に権限を確認したうえで、購入済み項目の復元と再入手の手順を確認してください。異なるシステムのアカウントやデータの手順を混同せずに済みます。

ローカル接続口とリモートサーバーのポートは別の設定

Proxy関連のポートは、まず用途を区別してください。Add Serverのポートは、利用者がすでにお持ちのリモートサーバー情報の一部です。ローカルProxyの待ち受けポートは、クライアントが他のアプリに提供する接続口です。どちらも「ポート」ですが、値を互いに転記してはいけません。リモートのポートは手元のサーバー情報に従い、ローカルポートはその接続口を使うアプリの設定と一致させます。現在のプラットフォームでHTTP、SOCKS5などのローカル接続口が提供されているか、追加のスイッチが必要かは、Settingsの実際の項目で確認してください。すべてのプラットフォームが同じとは限りません。

待ち受けアドレスとポートには、全プラットフォーム共通の推奨値はありません。まず現在の値とアプリ内の説明を確認します。同じ端末内でローカルProxyを使う場合は、まずローカル端末からのみアクセスできる範囲を維持してください。明確な目的がない限り、LANからの接続を許可しないでください。他の端末からアクセスさせる必要がある場合は、クライアントが対応しているか、システムネットワークで許可されているか、アクセス制御や認証の設定があるかを確認します。待ち受け範囲を広げると、単に接続が便利になるだけでなく、同じネットワーク内の端末がこの接続口にアクセスできる可能性もあります。誰が接続できるか、サービスをどう停止するかを明確にしてください。

アドレス・プロトコル・ポートを正しく組み合わせる

ローカル接続口を使うアプリでは、正しいプロトコル、アドレス、ポートをすべて設定する必要があります。番号が同じだからといってHTTPの接続口をSOCKS5として使うことはできません。リモートサーバーのアドレスを、ローカルの待ち受けアドレスの代わりにすることもできません。同じ端末からループバックアドレスへ接続する場合と、別の端末からその端末のLANアドレスへ接続する場合では、経路が異なります。別の端末で自分自身のループバックアドレスを指定しても、その端末自身に接続するだけで、Shadowrocketが動作している端末にはつながりません。問題を調べるときは、まずリクエスト元と接続口がある端末を確認してください。

ポートが競合すると、待ち受けを開始できなかったり、別のローカルアプリがリクエストを受け取ったりすることがあります。ポートを変更する前に元の値を記録し、新しいポートが使用中でないことを確認してください。変更後は、その接続口を使うすべてのアプリの設定を更新してから再テストします。一方だけ変更すると、クライアント側は正常でも呼び出し元が古い接続口を使い続けます。ローカルProxyの提供を停止した後は、呼び出し元のProxy設定も元に戻してください。閉じたポートへの接続を試み続け、システム全体のネットワーク障害のように見える場合があります。

問題の範囲に応じて確認順を決める

すべてのアプリで失敗する場合は、まず基本的なネットワーク接続、システムのVPN状態、選択中のサーバー、認証情報を確認します。ローカル接続口を使うアプリだけが失敗する場合は、プロトコル、待ち受けアドレス、ポート、アクセス範囲を調べてください。特定の対象だけ失敗する場合は、DNS、Global Routing、ルールの一致状況を確認します。問題を分類すると、関係のない設定変更を減らせます。LAN内の端末から接続できない場合は、同じネットワークに接続されているか、ゲスト端末の隔離やシステムファイアウォールの影響も考慮してください。リモートサーバーのテストに成功したからといって、LANの接続口にも到達できるとは限りません。

すべてをリセットすることが、完全な復旧とは限りません。まず直近の変更を取り消し、元のGlobal RoutingとConfigに戻します。続けてDNSとOn Demandを確認し、最後に呼び出し元のアプリにローカルProxy設定が残っていないか調べます。各段階を戻すたびに同じ対象へリクエストし、結果が変わった箇所が分かった時点で、それ以上の変更を止めてください。基準の状態に戻しても問題が続く場合は、該当するLogの短い抜粋とテスト条件を保存し、利用者のサブスクリプションが更新されたか、サーバー情報が変わったかを確認します。すべてを削除して解決を試みないでください。

再インストールやプラットフォーム変更が必要な場合は、全プラットフォームのダウンロードページから入手し、システムごとのインストール許可手順を確認してください。Windowsでは入手元を確認してからSmartScreenの案内に従います。Macでは入手元を確認し、システム設定の「プライバシーとセキュリティ」に表示される案内に従って許可します。Androidでは、システムの指示に従って該当するインストール元の権限を許可してください。インストール後はクイックスタートに沿って基本接続を復元し、その後で本ページの設定を一つずつ戻します。モードごとの違いを確認する場合はProxyモードの解説もご覧ください。一時的な診断用設定を、そのまま長期利用の設定にしないでください。