公式マニュアル · 初回接続

Shadowrocket はじめてガイド

読み込み、ルーティング選択、接続、確認、問題対処の順に進めます。初回は検証できる接続を1つ確立してから、ルールや自動接続を調整してください。複数の条件を一度に変更しないようにします。

情報を準備したら、まずサーバー情報が1件分なのか、複数の項目を更新できるサブスクリプションリンクなのかを確認します。入力先はそれぞれ異なり、リンクの見た目だけでは判断できません。不明な場合は、情報を提供した事業者に種類を確認してください。サブスクリプションリンク、パスワード、QRコードには認証情報が含まれる場合があります。公開のスクリーンショットやコメントに載せないでください。

01 · Add Server / Subscribe:既存情報を追加

Shadowrocket を開き、Home に進みます。初回はサーバー項目がまだ一覧にない場合があります。情報が読み込まれていない状態として正常です。右上のプラスボタンをタップして Add Server に進み、手元の情報に合わせて読み込み方法を選びます。以下のいずれか1つを行えばよく、同じ情報を何度も追加する必要はありません。

既存のサブスクリプションリンク:Subscribe を選択

Add Server の Type で Subscribe を選び、自分のサブスクリプションの完全なURLを URL に入力します。見分けやすい名前を付けて保存してください。貼り付けるときは、URL の前後に空白、改行、説明文が混ざっていないか確認します。自分のサブスクリプションを識別するためのパラメーターが含まれる場合があるため、URL の疑問符以降を削除しないでください。保存して更新が完了したら、Home に戻り、サブスクリプションのグループと、その中のサーバー項目を確認します。

サブスクリプション名が表示されても、サーバーが読み込まれたとは限りません。グループを展開するなどして、選択できるサーバー項目が実際に表示されていることを確認してください。グループだけがあり項目がない場合は、接続スイッチをオンにする前に更新結果を確認します。更新に失敗したら元のURLを保ったまま、サブスクリプションが有効か、現在のネットワークからそのURLにアクセスできるかを確認し、Shadowrocket で使える形式か事業者に問い合わせてください。表示させるためにURL内のパラメーターをむやみに置き換えないでください。

既存のサーバー1件:プロトコルに合わせて入力

サーバーのパラメーターを受け取った場合は、Add Server で情報に一致する Type を選んでから、アドレス、ポート、認証情報を入力します。プロトコルによって表示される項目は異なります。たとえば、Password を使うタイプもあれば、UUID を使うタイプもあります。これらの値は相互に置き換えられません。サーバーアドレス、TLS 関連の名前、通信経路にもそれぞれ用途がある場合があります。元の情報どおりに項目ごとに入力し、似た項目を1つの値にまとめないでください。プロトコル項目の詳細はプロトコル技術リファレンスをご覧ください。

事業者から QR コードを受け取っている場合は、Home の追加画面から Scan QR Code を使えます。読み込み後も項目の詳細を確認し、種類とアドレスを照合してください。スキャンによって入力の手間は省けますが、情報が有効であることの確認にはなりません。保存して Home に戻り、使うサーバーをタップして選択状態を確認します。ここまでで完了したのは「情報をクライアントに追加する」ことです。次に、どの接続を処理するかを決めます。

02 · Global Routing:接続経路を決める

Home で Global Routing をタップし、Config、Proxy、Direct を選択します。この3つは接続経路を決めるもので、サーバープロトコルの種類や速度の段階を示すものではありません。初回の確認では現在の選択を把握してください。同じサーバーでも選択内容によってアクセス結果が異なるため、設定が突然無効になったと誤解しやすくなります。

Config:既存ルールに基づいて振り分け

日常的にルールで振り分ける場合は Config を選択します。現在有効な設定に基づいて接続を処理するため、選択前に Config を開き、有効な設定があり、想定したものが選択されていることを確認してください。ルールは通常、上から順に照合され、一致すると対応するポリシーが使われます。DIRECT は直接接続し、PROXY はプロキシポリシーに渡し、REJECT は接続を拒否します。設定でポリシーグループを使う場合は、グループ内で実際に何が選択されているかも確認してください。Home でサーバーを選択しただけでは、すべてのポリシーグループがそのサーバーを使うとは限りません。

有効な設定がない場合、Config を選ぶだけで振り分けが完了したと思わないでください。まず次の方法でサーバーを確認してから、設定を整理します。内容を把握していない Config を上書きしないでください。既存の設定がある場合はコピーを残し、確認が必要なルールだけを後から変更します。Rule の照合順や設定の復元について詳しくはFAQをご覧ください。

Proxy と Direct:経路を明確にして確認

Proxy は、選択したサーバーで実際のリクエストを処理できるかを短時間確認するのに適しています。通常、クライアントが処理する接続をプロキシ経路に渡すため、まずルールの影響とサーバーの状態を切り分けられます。ただし、サーバーが使えるかどうかはアドレス、パラメーター、ネットワークにも左右されます。確認後にルールに従って使う場合は、Config に戻して再確認してください。Proxy で一度テストしただけでは、振り分け設定が正しい証明にはなりません。

Direct は、クライアントが処理する接続を直接接続します。プロキシサーバーが使えることの確認にはなりません。ネットワークの基準状態と比べたいときに使えますが、変更後は必要な設定に戻してください。Global Routing を選んだら Home に戻り、サーバーが正しく選択されていることを確認してから初回接続を行います。

03 · Home:スイッチをオンにして VPN 構成を許可

Home に戻り、選択したサーバーと Global Routing をもう一度確認してから、画面上部の接続スイッチをオンにします。初回接続時、iPhone / iPad に VPN 構成を追加するシステムの確認が表示される場合があります。直前に Shadowrocket で開始した操作であることを確認して許可し、システムの指示に従ってデバイスのパスコードまたは生体認証で認証してください。ここで許可するのは、デバイスにローカルの VPN 構成を作成することです。サーバーの購入や利用開始ではありません。

許可後に Shadowrocket に戻り、接続スイッチがオンの状態を保つか、クライアントに接続済みと表示されるか確認します。システム設定に VPN の状態が表示されても、それはシステム側で接続構成が有効になったことを示すだけで、サーバーが使えるという報告ではありません。サーバーのパスワードが間違っていたり、対象ドメインの名前解決に問題があったり、ルールの経路が想定と異なったりしても、接続状態が維持される場合があります。次のセクションで実際のアクセスも確認してください。

オンにした直後にオフになる場合は、初回のシステム確認をキャンセルしていないか思い出してください。システムの Settings を開き、VPN を検索して、該当する構成があるか、デバイスに管理上の制限がないか確認できます。学校や職場が管理するデバイスでは、その管理要件に従ってください。影響がわからないまま他の VPN 構成や構成プロファイルを削除しないでください。別の VPN が動作中の場合、接続に影響することがあります。テスト前に、どの構成が接続を担っているか確認してください。

初回は手動接続のままにし、On Demand を急いで有効にしないことをおすすめします。自動接続はネットワークの変化後に接続を再確立するため、「オフにして比較する」判断を妨げることがあります。手動での確認が済んでから、On Demand の適用条件を確認してください。接続中にスイッチを何度も素早く切り替える必要はありません。状態が落ち着くのを待って実際のエラーを記録してから次に進むほうが、問題の手がかりを残しやすくなります。

04 · Connectivity Test:テストと実際のアクセスを確認

まず Home で Connectivity Test を使い、サーバー項目に到達できるか確認して、選択した項目から結果が返るかを見ます。明らかなタイムアウトをすばやく見つけるのに適していますが、テスト方法や対象によって結果は変わります。表示された数値だけを実際の利用状況全体の評価としたり、1回のタイムアウトであらゆるリクエストが失敗すると判断したりしないでください。テスト後はサーバーと Global Routing の選択を変えずに、ブラウザーで実際にアクセスします。

普段使っていて、現在正常に動作するはずのウェブページを開き、読み込みが完了するか確認してから、別のサイトでも試します。1つのページだけをテストすると、サイト自体の障害、キャッシュされた内容、ログイン状態などが判断に影響することがあります。ページが表示されただけではプロキシ経路を確認できたとは限りません。Global Routing と現在の Config の Rule を照らし合わせ、このリクエストが DIRECT と PROXY のどちらを使う想定だったか確認してください。

クライアントの接続記録にリクエストの照合情報が表示される場合は、対象ドメイン、該当したルール、ポリシーを確認します。Config を使うとき、特定のサイトが正常に直接接続するのはルールどおりの場合があります。プロキシを経由しなかったからといって、接続が機能していないとは限りません。一方、PROXY に渡す想定のリクエストが計画どおり処理されない場合は、すぐにサーバー情報を変更せず、ルールの順序、設定の選択、ポリシーグループを確認してください。

状況を比較しやすくするため、現在の接続方法、Connectivity Test の結果、ブラウザーでの実際のアクセス結果の3点を記録します。必要であれば Proxy に1回だけ切り替えて、同じ対象を再テストします。Proxy では正常で Config では異常なら、まずルールやポリシーの設定を確認します。どちらも失敗する場合は、サーバーのパラメーターとネットワークを確認します。再テスト後は日常使用に必要な接続方法へ戻し、一時的な診断状態を長期設定として残さないようにしてください。

最後に、対象ページを閉じてからブラウザーで開き直し、古いキャッシュによる誤判定を減らします。同じページを何度も更新して、すべてのアプリの接続状態を推測しないでください。アプリによっては既存の接続を保持しているため、設定変更を確認するには新しいリクエストが必要な場合があります。「何を選択し、リクエストがどこへ向かい、どのような結果になったか」を説明できれば、初回の確認は完了です。

05 · よくある問題:複数箇所を同時に変えず、段階ごとに確認

接続に失敗したら、最初に想定どおりにならなかった手順から確認します。読み込みが完了していない場合は読み込みを修正し、サーバーテストがタイムアウトする場合はパラメーターを確認します。Config の結果だけが想定と異なる場合はルールを確認します。問題を段階ごとに分けることで、正しい設定を変更してしまい、1つの問題を複数に増やすのを防げます。

  1. Home に選択できるサーバーがない:サブスクリプションの下に項目が実際に作成されているか、更新時にエラーが出ていないか、1件分のサーバー情報を誤って Subscribe に入力していないか確認します。サブスクリプション名だけでは、内容の解析が完了したとは限りません。形式と有効な状態を自分の事業者に確認してください。先に Global Routing を変更する必要はありません。
  2. 項目はあるが Connectivity Test がタイムアウトする:項目の詳細を開き、アドレス、ポート、Password または UUID、TLS と通信パラメーターを1つずつ確認します。大文字と小文字、パス先頭のスラッシュ、コピー時に欠けた末尾の文字も確認してください。一般的な値だという印象だけでポートを変更せず、必ず自分の元情報に合わせます。
  3. テストとリクエストの両方が失敗する:デバイスの日付、時刻、タイムゾーンが正しいか確認し、システムの自動設定を有効にして再試行します。時刻のずれは証明書や認証に影響する場合があります。その後、可能であれば Wi-Fi とモバイル通信をそれぞれ使ってテストします。同じテスト中はサーバーとパラメーターを変えないでください。片方のネットワークだけで失敗する場合は、ネットワークの違いを記録し、設定全体をすぐに作り直さないようにします。
  4. 接続スイッチがオンの状態を保てない:システムの VPN 設定に戻り、追加の許可と現在の接続構成を確認してから、別の VPN が接続を引き受けていないか確認します。デバイスに管理上の制限がある場合は、デバイスの管理者に確認してください。競合の影響を理解し、元の設定を保管したうえで対処します。証明書をむやみに削除したり、デバイス全体のネットワークをリセットしたりしないでください。
  5. Proxy は使えるが Config の結果が想定と異なる:Config で正しいファイルが有効になっているか確認し、対象リクエストが照合した Rule と対応するポリシーを確認します。先に一致した広いルールによって、後の詳細なルールが実行されない場合があります。ポリシーグループの参照先が無効な項目だと、サーバー単独のテストは正常でも実際の接続が失敗することがあります。
  6. 特定のウェブページやアプリだけが異常:対象サービス自体の障害、ドメインの名前解決失敗、接続経路の誤りを切り分けます。すぐに TLS 検証を無効にしたり、DNS を広範囲に変更したりしないでください。異常が起きるドメイン、エラーメッセージ、現在のネットワーク、ルーティング方法を記録し、FAQ のルールと問題対処を読んで該当する症状に沿って確認します。

変更を1つ行うたびに、同じ対象を再テストし、結果が変わったか記録します。事業者に問い合わせる場合は、必要なエラー状況、プロトコルの種類、認証情報を伏せたパラメーターだけを伝え、サブスクリプションURL全体、認証情報、QRコードを公開しないでください。プロトコル項目の違いを理解するにはプロトコル技術リファレンスをご覧ください。初回接続の前にすべてのプロトコルを学ぶ必要はありません。

完了したら、読み込んだ情報、選択した項目、Global Routing の設定、テストと実際のアクセス結果を明確に記録しておきます。サブスクリプションの更新や Config の調整では、一度に1つの段階だけを変更して再確認してください。ネットワーク環境が変わっても、前回成功した状態から確認を始められます。