この記事の概要

Shadowrocketの接続後に速度が遅くても、クライアントやプロトコルが原因とは限りません。利用中のサービス事業者とサブスクリプションがあることを前提に、まずテスト条件をそろえ、ノード、回線、プロトコル、ローカルネットワークの順に比較します。遅延、転送速度、接続失敗を切り分け、再確認できる記録を残せば、設定の確認、接続ネットワークの切り替え、サービス事業者への問い合わせのどれが次の手順か判断できます。

まず基準を確認:低遅延でもダウンロードが速いとは限らない

遅延テストは特定の測定方法における応答時間を示し、スループットは一定時間に転送できるデータ量を示します。測定対象は異なります。ノード一覧で応答が速くても、目的のWebサイトまでの経路や継続的な転送能力、夜間の負荷が優れているとは限りません。一度タイムアウトしただけで、ノードが恒常的に使えないとも判断できません。

Homeで現在の接続状態、選択中のノード、Global Routingを確認します。測定方法を記録し、異なる方法で得た数値を同列に比較しないでください。アプリの接続許可が完了しても、リモートサービスへの一連のリクエストが正常に通るとは限りません。

テスト条件を固定 ノードを比較 時間帯ごとの回線状況を比較 プロトコルを確認 ローカルネットワークを切り替え
  1. ほかのデバイスやアプリによる大容量データの転送を止め、同じWebページまたはテスト用リソースを選びます。
  2. Global Routing、ノード、接続ネットワークを固定し、各条件で3回テストします。最速値だけでなく、結果の幅を記録してください。
  3. 「初回表示まで時間がかかる」「転送開始後に遅い」「途中で止まる」「まったく開けない」を分けて記録します。
  4. 各回で変更する条件は1つだけにします。切り替えたら接続を確立し直し、同じリクエストを実行して、既存の接続による影響を避けてください。

大容量ファイルのテストでは通信量を消費します。モバイル通信を使う場合は、契約プランの残量を先に確認してください。ここで示すテスト回数は切り分けの手順であり、性能基準や速度を保証するものではありません。

第1段階:利用中のノードを比較し、特定ノードの異常を切り分ける

Homeで利用中のノードの遅延テストを行い、同じ方法で連続して測定した結果を記録したうえで、実際のリクエストでも確認します。1つのノードだけが繰り返しタイムアウトし、ほかのノードでは同じ宛先にアクセスできる場合は、そのノードのアドレス、ポート、認証情報、サーバーの状態を優先して確認します。すべてのノードで異常がある場合は共通要因を調べ、やみくもに各パラメーターを変更しないでください。

確認された現象考えられること次の手順
特定のノードだけ繰り返しタイムアウトするそのエンドポイント、またはそこまでの経路に問題が集中している可能性サービス事業者から案内されたアドレス、ポート、有効状態を確認
遅延は安定しているが、継続的な転送が遅い疎通できても、スループットが制限されている可能性同じリソースを使い、継続的な転送速度を比較
すべてのノードで同時に速度が低下する共通の回線またはローカルネットワークが原因の可能性ノードを固定して、Wi-Fiとモバイル通信を切り替える
特定のWebサイトだけ遅い対象サービスまたは特定の経路に関係している可能性該当リクエストのルール判定と実際の出力先を確認

ノード名に含まれる地域名やラベルだけでは、実際の経路は分かりません。異なる名前のノードでも、出口を共有していることがあります。ノードのラベルは識別情報として扱い、回線が独立している証拠とは考えないでください。サブスクリプションを更新する場合は、既存のSubscribe項目から更新操作を行い、サブスクリプションURLは利用中のサービス事業者から入手します。更新後は選択中のノードが変わっていないか、もう一度確認してください。

まとめ:再現可能な比較用ノードを1つ選ぶ

利用中のノードから、同じリクエストを安定して完了できるものを比較用に1つ選びます。設定を1つ変更するたびに、同じ宛先で再確認してください。比較用ノードも同時に遅くなる場合は、まず共通要因を調べます。

第2段階:時間帯ごとの回線状況を記録し、混雑と接続先の制限を切り分ける

クライアントからノードまで、またノードから目的のサービスまで、どちらにもボトルネックが発生する可能性があります。特定の時間帯にすべてのリクエストが遅くなる場合は、共有経路の負荷が関係していることがあります。特定のサイトだけ遅い場合は、接続先による速度制限、コンテンツ配信経路、サービス側の障害も考慮してください。1回の速度テストだけでは、どの区間が混雑しているか特定できません。

同じデバイス、ノード、接続先を使い、問題が起きている時間帯と比較的空いている時間帯にそれぞれ記録します。異なるリソースを使うと、ファイルサイズ、キャッシュの有無、接続先の制限によって結果が変わり、比較の意味が薄れます。複数の速度テストを同時に実行しないでください。同じ帯域を取り合います。

同じ条件で特定の時間帯だけ繰り返し遅くなる場合は、記録を利用中のサービス事業者に送り、エンドポイントの負荷と経路の状態を問い合わせてください。DNSを何度も変更したり、同じサブスクリプションを再インポートしたりしても、リモート側の混雑が直接解消するわけではありません。速度テストの宛先には問題がなく、利用したいWebサイトだけで異常が起きる場合は、実際のリクエストを対象に調べてください。

第3段階:プロトコルと転送パラメーターを確認し、推測で変更しない

Home → Add Serverから手動入力する場合も、既存ノードの詳細を確認する場合も、プロトコル、ポート、認証情報、転送方式、TLSパラメーターはサービス事業者から提供された内容と一致させてください。ポート番号はエンドポイントの設定値です。たとえばサービス事業者が443を指定している場合に限って入力してください。HTTPSでよく使われるという理由で、すべてのノードのポートを置き換えてはいけません。

443
ポート確認例(すべてのノードに共通する既定値ではありません)
2項目
測定遅延と実際のスループットを分けて記録
1つ
各回で変更するテスト条件は1つだけ
プロトコル優先して確認する項目速度を調べる際の注意点
Shadowsocksアドレス、ポート、暗号化方式、パスワード方式やパスワードが一致しないとリクエストが失敗します。ポートへの疎通だけで判断しないでください。
VMess / VLESSUUID、転送方式、TLS、サービス事業者が指定するHostとパス種類を切り替えるだけでは相互に置き換えられません。転送パラメーターはサーバー側の設定と一致させてください。
Trojanパスワード、TLS、Server Nameドメイン名や証明書の検証に失敗した場合は設定を修正し、検証を無効にして接続しないでください。
Hysteria2認証情報、TLS、UDPの到達性QUICを利用します。接続ネットワークでUDPが制限されている場合、接続に失敗したり、動作が不安定になったりする可能性があります。
WireGuard鍵、エンドポイント、アドレス、ルーティング関連の設定UDPを利用します。サーバーがトラフィックを受信しているか、戻りの通信が正常かも確認してください。

Hysteria2は、パケットロスや遅延が大きい環境で有利な場合があります。ただし、効果はエンドツーエンドの経路とサーバー設定によって異なり、どのネットワークでも速くなるとは限りません。帯域幅のパラメーターを推測で入力したり、別のプロトコルのポート、認証情報、転送設定をそのまま流用したりしないでください。

エラー:connection refused

原因:接続先のエンドポイント、または経路上の機器が接続を拒否しています。ポートで待ち受けていない、またはアクセス方針で制限されている可能性があります。

対処法:アドレスとポートを確認します。同じエンドポイントでエラーが続く場合は、利用中のサービス事業者にサービスの状態を確認してください。

エラー:i/o timeout

原因:読み書き処理の一部が制限時間内に完了していません。このエラーだけでは、混雑、フィルタリング、サーバーから応答がない状態を区別できません。

対処法:エラーが発生した段階を記録し、ノードを固定して接続ネットワークを切り替え、比較用に選んだ既存ノードでも再テストします。

上記は接続ログに表示されることがあるエラーメッセージです。どのプロトコルでも同じ表現が表示されるとは限りません。最後の1行だけを切り取るより、実際のログの前後関係を残すほうが役立ちます。送信前に認証情報と個人的なアクセス履歴を削除してください。

通信経路を確認:遅いリクエストがテスト対象のノードを通っているか

Home → Global RoutingのProxy、Direct、Configは、リクエストの出力先に影響します。ノードを比較するときは、用途と通信量への影響を確認したうえで、一時的にProxyを使う方法があります。テストが終わったら、元の設定に戻してください。Configでは、Configで有効にしている設定と一致したルールを確認する必要があります。Directでの結果は、ノードのスループットを測定した結果にはなりません。

Sceneを使っている場合は、シーンに関連付けられた設定も確認してください。ノード一覧で選択されているかどうかだけでは、実際の出力先を判断できません。ルールは順番に照合されるため、ノードを何度も変更するより、対象リクエストがどのルールに一致したか確認するほうが直接的です。

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

以下はルールの意味を説明するもので、既存の設定を書き換える必要はありません。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPの地理情報に基づいて照合し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。例のexample.comは説明用のドメインです。実際の設定では独自のポリシー名が使われる場合もあります。

第4段階:ローカルネットワークを切り替え、Wi-Fiと接続開始の要因を切り分ける

ノードと接続先を固定し、Wi-Fiからモバイル通信に切り替えて、接続し直してからテストします。モバイル通信では正常でWi-Fiでは異常がある場合、原因の範囲をそのWi-Fiの電波品質、ルーター、上位回線、ネットワークポリシーに絞れます。ただし、この結果だけで故障機器を特定することはできません。切り替え時にノードやGlobal Routingも変わった場合は、先に同じ条件に戻してください。

  1. ローカルネットワークの基準を確認:プロキシを使わずにアクセスできる対象で、接続前後の状態を比較します。プロキシを経由しなくても遅い場合は、まず接続ネットワークを確認してください。
  2. Wi-Fiの電波状態を確認:ルーターの近くで再テストし、上り通信を占有する大容量の処理を一時停止します。上り帯域が埋まると、応答時間も長くなります。
  3. 認証を確認:公共のWi-FiでWeb認証が必要な場合は、そのネットワークの認証を済ませてから接続を再試行します。
  4. 接続開始の設定を確認:Settings → On Demandで接続条件を確認します。テスト中に接続が再度開始された場合は、その時刻を記録し、設定した条件に合致しているか確認してください。
  5. 接続の併用状態を確認:システムのVPN設定で現在実際に有効な接続を確認します。接続状態の切り替わりを、同じトンネルの速度が低下し続けていると誤認しないようにしてください。

よくある質問と問い合わせ時の確認事項

遅延は低いのに、動画がずっとバッファリングするのはなぜ?

遅延テストは、動画の経路で継続的に得られるスループットを示すものではありません。ノードとGlobal Routingを固定し、同じ動画の読み込み状況を比較して、該当リクエストが実際に一致したルールを確認してください。このサービスだけで問題が起きる場合は、接続先のホスト名と発生時間帯を記録します。

サブスクリプションを更新したら遅くなりました。ノードをすべて入力し直す必要がありますか?

まず、更新後に選択されているノード、プロトコル、ポートが変わったか確認し、更新前に記録した情報と比較してください。すべての設定をすぐに削除しないでください。サブスクリプションの内容や有効性に疑問がある場合は、利用中のサービス事業者に確認します。

Wi-FiでだけHysteria2が不安定です。どう確認できますか?

そのノードの設定は変えずに、モバイル通信へ切り替えて再接続し、同じリクエストを繰り返します。そのWi-Fiでだけ異常が起きる場合は、UDP関連のエラーと接続時刻を記録してください。原因の範囲を絞る手がかりにはなりますが、現象だけでネットワークがUDPを確実に遮断しているとは断定できません。

iPhoneを再起動しても遅い場合、問い合わせには何を伝えればよいですか?

日時とタイムゾーン、接続の種類、ノードのラベル、プロトコル、Global Routing、接続先のホスト名、比較テスト3回分の結果を伝えます。エラーの前後関係は機密情報を伏せて添付してください。パスワード、鍵、UUID、サブスクリプションURL全体は送信しないでください。

確認が終わったら、Global RoutingとOn Demandを元の設定に戻し、有効な記録を残します。特定ノードだけの異常ではエンドポイント、特定時間帯の異常では回線、特定プロトコルの異常では転送条件を優先して確認します。特定の接続ネットワークだけで異常がある場合は、ローカルネットワークを調べてください。クライアントの買い切りと回線プランは別のものです。クライアントを再購入しても、利用中の回線の帯域や負荷は変わりません。