Shadowrocketプロトコルガイド

1. プロトコルの選び方：設定を4つの階層に分けて確認

プロトコルの種類はサーバーと一致させる

Shadowrocketでプロトコルを選ぶ際、一覧から「最速」のものを探すわけではありません。サーバーが待ち受けているプロトコルと同じ種類をクライアントでも指定する必要があります。同じアドレスとポートを使っていても、プロトコル名だけを変更して接続できるとは限りません。サブスクリプションにプロトコルの種類が指定されている場合は、まずその設定を維持してください。Add Serverから手動で追加する場合は、サーバーのアドレス、ポート、認証情報に加え、相手側から明示された転送方式や暗号化の設定を確認します。情報が足りないときは、選択肢を次々と試すより、利用中のサービスの設定説明に戻って確認するほうが確実です。

設定は4つの階層に分けて考えると理解しやすくなります。1つ目は接続先を決めるアドレスとポート、2つ目は双方が認証やリクエストの交換に使う形式を決めるプロトコルと認証、3つ目はリクエストを運ぶ転送方式、4つ目は接続先の認証と通信の保護に関わるTLSなどのセキュリティ設定です。プロトコルによっては複数の階層をまとめて実装しているため、追加画面にすべての項目が表示されるとは限りません。項目が表示されないからといって機能がないとは限らず、別の種類の設定項目をそのままコピーするのも避けてください。

速度、バッテリー消費、安全性は別々に考える

速度には、接続の確立、最初の応答、継続的なデータ転送という少なくとも3つの段階があります。ハンドシェイクが少なければ、ウェブページを最初に開くまでの待ち時間が短くなる場合があります。輻輳制御が適切なら、長時間の転送が改善することもあります。また、サーバーの負荷が低ければ、一般的なプロトコルでも安定して動作する可能性があります。バッテリー消費には、無線信号の強さ、再送、バックグラウンドでの復帰、接続維持の頻度も影響します。プロトコル名だけから、消費電力の決まった順序を判断することはできません。電波の弱いモバイル回線では、再接続の繰り返しによる負荷が、暗号化方式の違いより大きくなる場合もあります。

認証と暗号化も分けて考えましょう。パスワードやUUIDは利用者を識別する情報であり、それだけで通信のすべてが暗号化されるわけではありません。TLSでクライアントからサーバーまでの通信を暗号化しても、その先のサーバーから接続先ウェブサイトまでを、このプロトコルがすべて保護するとは限りません。ウェブサイトにアクセスする際は、サイト自体の安全な接続も確認してください。実用的な選び方の第一歩は、すべての安全性をひとつの名称で判断することではなく、通信経路全体のどこまでが各設定の対象かを確認することです。

プロトコルとルーティングの役割

Global Routingは、ルールに通信経路を選ばせるかどうかを決めます。プロトコルは、サーバーに渡された接続をどのように転送するかを決めます。Configモードでは現在の設定に従って処理し、Proxyモードでは対象の通信を選択したプロキシ経由で処理し、Directモードでは直接接続します。この3つのモードを切り替えても、誤ったパスワードやポートは直りません。プロトコルを変更しても、誤って設定されたDIRECTやREJECTルールが自動で修正されるわけではありません。診断時には「サーバーを経由しているか」と「サーバー経由で通信できるか」を分けて確認してください。

問題を再現できる元の設定をまず保存し、そのうえで項目をひとつずつ調整してください。サーバー名は識別に使えますが、実際のプロトコルを示すものではありません。同様に、地域のラベルから物理的な距離や実際の経路が分かるわけでもありません。同じ名前の項目がインポート前後で変わった場合は、名前だけでなく設定項目を比較してください。プロトコル関連の項目表示は、現在のアプリで確認できる内容に従ってください。このページは設定項目の意味を説明するもので、特定のサーバー構成をすべての利用者に推奨するものではありません。

2. Shadowsocks：軽量な転送と暗号化方式

軽量なプロキシ転送を重視した設計

Shadowsocksは、暗号化されたプロキシ転送を中心に設計されており、接続先のアドレスとアプリのデータをカプセル化してサーバーへ渡します。端末全体をネットワークに接続するトンネル型プロトコルではなく、端末用のトンネル内アドレスを割り当てる必要もありません。クライアントの利用者が確認する主な情報は、サーバーアドレス、ポート、パスワード、暗号化方式です。項目が少ないことで手入力は簡単になりますが、どれも省略できるわけではありません。特に暗号化方式は、サーバーで実際に設定されている値を使う必要があります。

初期のストリーム暗号と、後から登場したAEAD方式では、完全性の保護やメッセージの処理方法が異なります。AEADはデータの機密性と完全性の検証を同時に行います。名称が似ているからといって、旧方式と入れ替えて使うことはできません。世代の異なるプロトコルでは、鍵の長さ、エンコード、認証の構造も異なる場合があります。指定形式のキーが案内されている場合、独自に一般的な短いパスワードへ変更しないでください。クライアントで組み合わせを認識できない場合は、名称が似たものを選ぶのではなく、双方の対応状況を確認してください。

Passwordと暗号化方式をセットで確認する

Passwordは重要な認証情報です。コピーする際は、前後の空白、改行、全角文字に注意してください。暗号化方式は対応する鍵情報の扱い方を決めるため、両方をサーバーの設定に合わせる必要があります。入力した項目を保存できたとしても、フォームで受け付けられたことを示すだけで、サーバー側の認証に成功したとは限りません。遅延テストの結果が表示されてもウェブページにアクセスできない場合、パスワードが正しいとは断定できません。テストによって確認する接続段階が異なる場合があるため、実際のリクエストとアプリ内のログをあわせて確認してください。

既存の設定によっては、追加の転送拡張項目が含まれています。これらはサーバーとの組み合わせの一部であり、一般的な項目を自動的に高速化するスイッチではありません。他の項目にあるHost、パス、拡張オプションを現在の項目にコピーしたり、説明がないまま有効にしたりしないでください。サブスクリプションからインポートした項目が更新後に元の値へ戻る場合、これらの項目が引き続きサブスクリプションで管理されている可能性があります。比較する際はテスト用の項目を別に保存し、手動での変更が更新で上書きされて診断材料を失わないようにしてください。

TCP、UDPと実際の使い心地

ShadowsocksはTCPとUDPの転送に対応する場合がありますが、どちらの通信が正常に使えるかは、サーバーの機能とネットワーク環境にも左右されます。ウェブページが表示されても、UDPに依存するアプリの通信が正常とは限りません。反対に、アプリで音声が聞こえない、長時間待たされるといった現象があっても、すぐにプロトコルが原因とは判断できません。まず利用中のサーバーがどの通信に対応しているかを確認し、次にクライアント側の関連設定を調べてください。動作確認では大容量の通信を続けるのではなく、実際の用途で必要なリクエストをいくつか試してください。

iPhoneでは、簡潔なカプセル化によって一般的な短時間の接続処理がシンプルになる場合がありますが、結果は暗号化方式、端末のハードウェア、サーバーの帯域、ネットワークのパケットロスにも左右されます。「構造がシンプルだから消費電力が少ない」と一律に保証することはできません。長時間のダウンロードでは画面の状態や無線接続がバッテリー消費に大きく影響します。待機中は接続の維持やバックグラウンドでの通信が重要になる場合があります。既存の2つの項目を比較する際は、同じネットワーク、同じコンテンツ、近い時間帯で試し、条件の違いをプロトコルの違いと取り違えないようにしてください。

よくある確認手順は、アドレスとポート、暗号化方式とパスワードの入力、追加の転送項目、UDPの条件の順です。一部のウェブサイトだけ失敗する場合は、すぐに項目を作り直さず、ルール、DNS、接続先への到達性を確認してください。すべてのリクエストが失敗し、直接接続では問題ない場合は、失敗した時間とエラーの種類を記録し、サーバーの待受状態と認証状態を確認します。サーバーのテスト結果と実際のウェブ閲覧の違いについては、遅延テストと実際の使用感をご覧ください。

3. VMessとVLESS：認証、転送方式、TLS

設定項目が似ていても、同じプロトコルとは限らない

VMessは、ユーザー認証とデータ転送を組み合わせたプロトコルです。UUIDなどの情報で利用者を識別し、プロトコル層で対応するセキュリティ処理やデータ形式を扱います。VLESSはよりシンプルな設計を採用し、安全な通信経路の役割をTLSなどの外側の仕組みに委ねる部分が多くなっています。どちらもUUID、転送方式、TLSの項目が表示される場合があるため、画面上の見た目は似ていますが、同じプロトコルの別名ではありません。サーバーがいずれか一方に設定されている場合、クライアント側で種類だけ変更して、すべての設定をそのまま使うことはできません。

シンプルな設計だからといって、あらゆる条件で高速になるわけではなく、安全設定を省略できるわけでもありません。VLESS自体はVMessと同じデータ暗号化の役割を担わないため、実際の保護は転送方式を含む全体の組み合わせで決まります。既存サービスの説明を読む際は、プロトコル名だけでなく、転送方式とセキュリティ設定を一体として確認してください。たとえば「VLESSを使用する」という情報だけでは設定の一部しか分かりません。接続先、認証識別子、外側のセキュリティ方式、指定された転送項目の有無も確認する必要があります。プロトコル名から各項目の初期値を推測しないでください。

UUID、時刻、旧式の設定項目

UUIDは認証用の識別子です。形式や文字をそのまま保ち、自由に付けるメモのように扱わないでください。サブスクリプションをインポートしたら、まずプロトコルの種類と識別子が正しく読み込まれているかを確認し、次に追加項目を確認します。VMessの認証処理には時刻の条件があるため、端末の時刻が大きくずれているとハンドシェイクに失敗する場合があります。まずシステムの日付と時刻が正しいか確認してください。古い設定項目の説明を見かけても、現在の項目に過去の設定を追加したり、古い組み合わせがすべてのサーバーで使えると思い込んだりしないでください。

Encryptionなどの項目がある場合は、選択中のプロトコルに応じて意味を確認してください。あるプロトコルで使われる値を、別のプロトコルにそのまま流用することはできません。クライアントで入力欄が表示されても、サーバーがすべての値を受け入れるとは限りません。手動で追加する前に、「明示されている項目」と「説明にない項目」を分けて整理し、説明にない項目はアプリで適用される初期状態のままにしてください。必要であれば利用中のサービスに確認しましょう。根拠のない入力を試すと複数の条件が同時に変わり、後から原因を特定できなくなります。

WebSocket、gRPCと証明書名

WebSocketは転送方式のひとつで、パスやリクエストのHostを設定する場合があります。gRPCの組み合わせでは、サービス名などの項目が必要になることがあります。パスでは大文字と小文字が区別される場合があり、先頭のスラッシュ、末尾の文字、エスケープの違いも照合結果に影響します。サーバーアドレスは接続先を示し、Hostはリクエストの処理対象を指定するために使われ、SNIはTLSハンドシェイクでサーバー名を伝えます。これらの値は同じ場合も異なる場合もあるため、既存の設定に従って入力してください。あるドメインが名前解決できるからといって、すべての名前欄に同じ値を入力しないでください。

TLSの検証では、証明書の名前が接続先として指定したサーバー名と一致し、証明書チェーンも正常に検証できる必要があります。証明書エラーを通常の対処として無視するのは避けてください。まず端末の時刻、SNI、アドレスの入力内容、証明書の有効性を確認し、その後でサーバー側の設定を調べます。ALPNはアプリケーション層のプロトコルをネゴシエーションするための設定です。指定値も実際の転送方式に合わせる必要があります。名前をむやみに追加しても互換性は高まりません。サーバーの要件に合わず、ハンドシェイクに失敗することもあります。

モバイル回線では、転送の層が増えるとカプセル化やハンドシェイクの処理が増える場合がありますが、実際の影響は接続の再利用、サーバーの処理能力、ネットワーク品質によって異なります。短いリクエストを頻繁に開く場合と、大容量ファイルを継続して転送する場合とでは結果が異なることがあります。トラブル時は、まず設定が正しい単一の項目で安定して接続できる状態にし、既存の利用可能な組み合わせと比較してください。「接続済みなのにページが表示しきれない」場合は、DNS、ルール、接続先への通信も確認します。UUIDだけを何度も変更しないでください。

4. Trojan：TLS経由でプロキシリクエストを転送

TLSをセキュアな通信経路として使用

Trojanは、TLS接続内で認証とプロキシリクエストを送受信し、広く使われているTLSの仕組みでクライアントからサーバーまでの通信を保護する設計です。TLSを使う別のプロトコルと互換性があるわけではありません。TLSは外側の安全な通信経路にすぎず、その内側ではTrojan固有の認証とリクエスト形式に従う必要があります。サーバーで安全なウェブページ用ポートが開いていても、そのポートをTrojanの接続先として使えるとは限りません。クライアントでTLSハンドシェイクが完了しても、その後のプロキシ認証に成功したとは限りません。

一般的な設定では、アドレス、ポート、Password、サーバーと一致するTLS名が必要です。Passwordはプロトコルの認証情報で、証明書は接続先サーバーの身元を確認するためのものです。それぞれ役割が異なります。パスワードが正しくても証明書の検証に失敗すると接続が切断される場合があります。証明書が正しくてもパスワードが違えば正常に転送できません。この違いを理解すれば、エラーを「安全な通信経路を確立できない場合」と「経路の確立後に認証またはリクエストが失敗する場合」に分けられます。毎回すべての項目を最初から変更する必要はありません。

アドレス、SNI、証明書チェーンの関係

接続先アドレスにはドメイン名または明示されたIPアドレスを使います。SNIはTLSハンドシェイクで送るサーバー名で、通常はサーバーの設定で指定された名前を使います。IPアドレスで接続し、証明書がドメイン名に対して発行されている場合は、名前の検証条件を特に確認してください。「このIPに接続できる」からといって、どのSNIでも使えるわけではありません。ひとつの接続先で複数のサービスを提供している場合、サーバー名によって処理先が選ばれることもあります。名前が誤っていると、返される証明書や応答もまったく異なる場合があります。

証明書チェーンの検証では、信頼できる発行元までの経路、有効期間、名前の一致を確認します。エラーが発生したら、まずシステム時刻を確認し、次にアドレスやSNIに余計な文字がないか、最後にサーバー側の証明書の状態を調べてください。検証を長期間無効にすることを、一般的な対処方法として勧めるべきではありません。サーバーの身元を確認する機能が弱まるためです。既存のサービスで特殊な証明書設定を使う場合は、信頼設定とリスクの範囲を把握したうえで、案内に従って対応してください。関係のない項目から検証設定をコピーしないでください。

ハンドシェイクの負荷とモバイル端末での動作

TLSハンドシェイクでは接続時にネゴシエーションと応答待ちが発生しますが、Trojanに限った負荷ではありません。TLSを使う他の組み合わせでも同様の処理が行われます。接続の再利用、セッション再開、ネットワークの往復時間によって、実際の使用感は変わります。短時間に複数のウェブページを開く場合と、同じ接続を長時間維持する場合とでも結果は異なります。「TLSを使うと必ず遅くなる」「特定のポートなら必ず省電力になる」といった結論は信頼できません。同じネットワーク条件で実際のタスクを試してください。

iPhoneでWi-Fiからモバイル回線に切り替えると、既存の通信接続を再確立する場合があります。短時間待てば復旧するなら、すぐにパスワードの誤りと判断せず、まず回復するか様子を見てください。ネットワーク切り替えのたびに接続できなくなる場合は、現在のネットワークからの到達性、ドメインの名前解決結果、サーバーの接続先の状態をそれぞれ確認します。再接続を繰り返すと無線通信と処理の負荷が増えます。高度な設定を何度も切り替えるより、サーバーの設定が安定しているか、接続の動作が適切かを先に確認してください。

TrojanでUDPを転送できるかどうかは、サーバーの実装、クライアントの対応機能、実際の設定によって異なります。種類名だけで、すべてのアプリが正常に動くとは判断できません。ウェブは使えるのに特定のリアルタイム通信が失敗する場合は、そのアプリに関係するネットワーク条件を記録し、UDPとルールの経路を確認してください。特定の接続先だけ失敗する場合は、接続中なのにインターネットにアクセスできない場合の確認手順を参照し、すべての問題を証明書やプロトコルの種類だけに結びつけないようにしましょう。

Trojanをそのまま使うのが適切なのは、必要な項目がそろい、証明書が正常に設定され、実際に安定して動作する接続先をすでに利用している場合です。手元の情報がパスワードだけで、必要な名前や転送方式が不明なら、まず情報をそろえてください。特定のプロトコルが優れているという印象だけで、現在使えている別の項目をTrojanに変更しないでください。最終的な選択は、一度の接続テストの数値だけでなく、サーバーの機能、実際の用途、設定の管理しやすさを踏まえて行います。

5. HTTPとSOCKS5：汎用プロキシの役割と制限

プロキシへの接続とウェブサイトへのアクセスは別の層

HTTPプロキシは、一般的なアプリケーション層のリクエスト転送を目的として使われます。HTTPSサイトへアクセスする際は、クライアントがCONNECTリクエストで接続先までのトンネルを確立し、その後のウェブ通信をサイト自身のTLSで保護できます。ここでは、端末からプロキシサーバーまでの通信が暗号化されているかどうかと、端末から接続先サイトまでの通信がサイト自身の安全な接続で保護されているかどうかを分けて考えてください。接続先のURLがHTTPSだからといって、端末からプロキシまでのすべてのリクエストや認証情報も同じように保護されているとは限りません。

既存の接続先でプロキシ通信をTLSで保護することが明示されている場合は、アプリ内で対応する種類とセキュリティ設定を使ってください。接続先のウェブサイトがHTTPSだからといって、独自に設定を有効にしないでください。通常のHTTPプロキシ用ポートと、セキュアなプロキシ用ポートは異なる場合があり、認証条件も異なることがあります。サーバーアドレス、ポート、ユーザー名、パスワードはセットで確認してください。認証に失敗した場合は認証情報とサーバー側の権限を確認します。ハンドシェイクに失敗した場合は、通常の接続先をTLS対応の接続先と誤認していないかを確認してください。

SOCKS5は接続先への転送を重視する

SOCKS5は汎用的なプロキシのネゴシエーションと接続先アドレスの指定方法を提供し、ウェブの内容を解釈することを前提としません。複数の認証方式を利用でき、UDP転送の仕組みも定義されていますが、プロトコル自体がすべての通信を自動的に暗号化するわけではありません。ユーザー名とパスワードは認証のためのもので、安全な通信経路が確立されたことを意味しません。利用中のサービスで追加の保護が必要な場合は、実際の設定を確認してください。Passwordの入力欄があるだけで、通信の機密性を判断することはできません。

SOCKS5でUDPを転送するには、サーバーが対応していることに加え、中間のネットワークが該当するデータを通せる必要があります。TCP接続は正常でもUDPリクエストだけ失敗することがあります。リアルタイム通信や特殊なアプリの通信が必要な場合は、まず利用中のサービスがUDPについて明示しているか確認し、実際のリクエストで動作を確認してください。ポートを何度も変更して対応状況を推測したり、一度のウェブテスト成功を「すべての通信を検証済み」とみなしたりしないでください。

DNSの解決場所によって結果が変わる

プロキシリクエストでは、接続先ドメイン名がそのまま送られる場合もあれば、途中で接続先のIPアドレスに変換される場合もあります。実際のDNSの経路は、アプリ、Shadowrocketの設定、サーバー側の処理方法に左右されます。そのため、特定の汎用プロキシが常にローカルで名前解決する、または常にリモートで解決すると一概には言えません。IPアドレスではアクセスできるのにドメイン名では失敗する場合は、認証情報を再入力するだけでなく、DNSの応答、ルールの一致、プロキシリクエストでのアドレス形式を確認してください。

企業内または自分で管理するネットワークのプロキシでは、接続先のポートやアドレス、リクエスト方法が制限されている場合があります。認証の成功は必要なアクセス権を得る手順のひとつですが、任意の接続先へアクセスできることを意味しません。HTTP CONNECTが拒否された場合、接続先ポートが許可範囲外の可能性があります。SOCKS5のリクエストが拒否された場合も、サーバー側のポリシーや接続先への到達性が原因かもしれません。エラーが発生した段階に応じて、接続先に到達できない、認証に失敗する、接続先に拒否される、接続先への接続確立に失敗するといった状況を切り分け、それぞれに合った箇所を確認してください。

iPhoneでは、利用中の環境がHTTPまたはSOCKS5プロキシを提供している場合に適した接続方式です。設定項目はなじみのあるものですが、他のプロトコルより必ず速い、省電力になるとは限りません。接続先の制限が多いとアプリが再試行を繰り返し、かえって待ち時間や通信量が増える場合があります。動作確認では、許可された範囲で実際の接続先をひとつ試してから、必要なアプリの種類を確認してください。既存項目の見た目をそろえるために、暗号化されたプロトコルをHTTPやSOCKS5に変更しないでください。プロトコルが異なるため、サーバー側に対応する接続先が必要です。

6. WireGuard：鍵、トンネル内アドレス、ルーティング範囲

プロキシ接続からネットワーク層のトンネルへ

WireGuardはネットワーク層のトンネル向けに設計されており、現代的な暗号方式の組み合わせと公開鍵によるピア認証を使用します。個々のプロキシリクエストを処理するプロトコルと比べ、ピア、トンネル内アドレス、転送を許可するネットワーク範囲を重視します。そのため、接続先アドレスのほかに、自分側の秘密鍵、相手側の公開鍵、トンネル内アドレス、ルーティング関連の情報が設定に含まれることがあります。項目が多く見えても、それぞれを利用者が独自に決める必要があるとは限りません。通常は既存サーバーから提供された設定一式をもとに、項目ごとに確認します。

WireGuardは主にUDPで通信します。一般的なウェブ閲覧ができるネットワークでも、指定された接続先へのUDP通信が許可されているとは限りません。また、あるポート番号へのTCP接続テストの結果から、同じ番号のUDP接続先が使えるとは判断できません。トンネルのハンドシェイクが確立しない場合は、ウェブサイトのルールではなく、アドレス、ポート、ネットワーク環境、ピアの鍵を確認してください。サーバーの接続先にリクエストが届くかどうかと、トンネル内の接続先へアクセスできるかどうかは、別々の段階です。

Private Key、Public Key、アドレスの役割

Private Keyは自分側の重要な識別情報です。公開された掲示板などに送信したり、相手側の公開鍵で代用したりしないでください。Public Keyは相手側のピアを識別するために使われ、サーバー側にも接続を許可するクライアントの公開鍵を登録する必要があります。事前共有鍵が設定に含まれる場合は、双方の指定に合わせて入力してください。自分側だけで使う値をその場で生成しても意味がありません。鍵の形式が入力欄の要件に合っていても、エンコードが有効な可能性を示すだけで、サーバーに接続権限が設定されているとは限りません。

トンネル内アドレスと接続先アドレスは別のものです。接続先アドレスは現在のネットワークからサーバーを見つけるために使い、トンネル内アドレスはトンネル確立後の通信に使います。サーバーのパブリックアドレスを自分側のトンネル内アドレスに入力しても、通常は正しく動作しません。DNSアドレスについても、トンネル内でしかアクセスできないものか確認してください。設定で内部のDNSサーバーを使う必要があり、トンネル自体がまだ確立していない場合、ドメイン名でアクセスできないのは後続の症状かもしれません。DNSの項目をすべて別の値に変更する前に、トンネルの状態を確認してください。

Allowed IPs、MTU、接続維持

Allowed IPsは、ピアに関連付けるアドレス範囲とルーティング先の定義に使われます。一般的なウェブサイトの許可リストではありません。範囲が狭すぎると、想定した通信がその経路を通らない場合があります。広すぎると、別の経路を使うはずの接続にも影響する可能性があります。Shadowrocketでは、現在のGlobal Routingや設定での実際の処理方法もあわせて確認してください。サーバー側のアドレス範囲の説明を、アプリ内の各ルールと同じものと考えないでください。変更前に、アクセスしたい対象が内部リソースなのか、一般のインターネット上の接続先なのかを整理しましょう。

MTUは、ひとつのネットワークパケットで送信できるデータ量に関係します。カプセル化によって利用できる領域が小さくなるため、経路上の分割やパス検出に問題があると、小さなリクエストは通るのに、大きなページや長時間の転送が止まることがあります。MTUを下げることで原因を特定しやすくなる場合はありますが、低くしすぎるとパケット数と処理負荷が増えます。全員に共通する「最適値」はありません。既存の設定を基準に、少しずつひとつの項目だけを変え、同じ条件で再現できるリクエストが改善したか記録してください。

接続維持の仕組みは、ネットワーク機器上の一部のマッピングを維持するのに役立つことがあります。一方、定期的なデータ送信には通信量と端末の復帰に伴う負荷があります。モバイル回線では「安定させる」ために間隔をむやみに短くしないでください。現在の接続が安定しているなら、バックグラウンド通信を増やす必要はありません。バッテリー消費を比較する際は、On Demandの条件による接続の繰り返しも考慮してください。WireGuardのシンプルな設計は実装の複雑さを抑える助けになりますが、端末の消費電力はネットワーク、転送量、接続維持の頻度によって変わります。

この方式は、利用者が接続先のピアとネットワーク範囲の設定を把握しており、特に自分で管理するネットワークのリソースにアクセスする場合に適しています。トラブル時は、ハンドシェイクを確認し、次にトンネル内アドレスをテストし、最後にドメイン名とアプリのリクエストを確認します。順番を逆にすると、ルーティングや名前解決の問題を鍵の誤りと取り違える可能性があります。設定を復旧できるよう、元の内容を保存してください。ひとつの接続先を直すためにアドレス範囲全体をむやみに広げたり、秘密鍵を含むスクリーンショットや設定一式を公開したりしないでください。

7. Hysteria2：QUIC、帯域、弱いネットワークでの考え方

不安定なネットワークを想定した転送設計

Hysteria2はQUICを基盤とするプロキシ転送方式で、遅延やパケットロスが多い環境でのデータ転送を考慮した設計です。QUICは通常UDP上で動作し、安全な接続と複数のデータストリームの仕組みを統合しています。次の2点は分けて考えてください。特定のネットワーク上の問題に配慮して設計されていても、あらゆるネットワークで高速になるとは限りません。クライアントが対応していても、現在のネットワークから指定されたUDP接続先にアクセスできるとは限りません。選択する前に、既存サーバーが類似名の別方式ではなく、実際にHysteria2を提供していることを確認してください。

QUICを基盤とする転送方式は、複数の論理ストリームをひとつの信頼性の高いバイトストリームに単純に重ねる場合に起こる問題を避けますが、データは同じネットワーク経路と利用可能な帯域を共有します。パケットロスが大きい場合、サーバーの負荷が高い場合、ネットワークがUDPを適切に処理できない場合は、使用感が悪化することがあります。複数のストリームがあるからといって「パケットロスが速度に影響しない」わけではありません。また、大容量ファイルの一度のテスト結果を、短いリクエスト、リアルタイム通信、バックグラウンド同期など別の用途にそのまま当てはめないでください。

認証とTLSを個別に確認する

一般的な設定には、接続先アドレス、ポート、認証情報、TLS名に関する項目が含まれます。認証情報は利用者の確認に使い、TLSは安全な通信経路とサーバーの身元確認を担います。他のプロトコルと同じように、それぞれの役割を分けて理解してください。認証エラーが出た場合は、利用中のサービスから提供された認証情報を確認します。証明書や名前のエラーが出た場合は、SNI、システム時刻、サーバー側の証明書を確認してください。QUICを使うからといって、証明書の検証を省略したり、名前を自由に選んだりしないでください。

既存の設定によっては、特定の難読化パラメーターやポートに関する設定が必要なことがあります。これらは双方で一致させる必要があります。クライアントだけで有効にし、サーバー側で同じ設定を使っていない場合、正常に通信できないことがあります。インポート後は、まずサブスクリプションから読み込まれた設定を維持してください。手動で追加する場合は、明確な説明に従って入力します。資料に記載されていない拡張項目は、設定を複雑にするためだけに追加しないでください。画面に高度な項目が表示されるのは設定機能を提供するためであり、すべての利用者に有効化を求めるものではありません。

帯域の設定値は実測速度ではない

設定によっては、上り・下りの帯域情報を送信動作の制御に使用します。入力値は、項目の説明、実際のネットワーク環境、既存サービスの要件をもとに判断してください。モバイル回線のアイコンが示す理論上の速度をそのまま入力するものではありません。数値を大きくしても、回線の容量が増えるわけではありません。実際より大きく見積もると、通信の滞留やパケットロスが起こりやすくなり、ページ表示や他のアプリに影響する場合があります。低く見積もりすぎると、利用できる通信速度を制限する可能性があります。再現可能なタスクを使い、段階的に様子を見てください。

単位にも注意してください。ビット毎秒とバイト毎秒は異なり、回線の公称速度とアプリのダウンロード表示も単純に比較できません。既存の設定で自動調整が使われている場合は、「最適化」のためだけに手動の帯域設定へ変更しないでください。手動で設定する必要がある場合は、上りの通信能力も考慮します。ダウンロード中にも確認応答や制御情報の送信が必要です。他のアプリが上り回線を使い切ると、下りの通信にも影響することがあります。テスト中は関係のない大容量通信を一時停止し、原因を誤って判断しないようにしてください。

iPhoneでは、電波が弱い状態で高いスループットを得ようとすると、無線通信、処理、再送が増える場合があります。端末の発熱やバッテリー消費の変化を、プロトコル名だけのせいにすることはできません。短時間のテストでは、画面の明るさ、充電状態、バックグラウンドのタスクも影響します。日常的なウェブ閲覧やメッセージが主な用途なら、一度の最高速度より、応答の安定性やネットワーク切り替え後の復旧を優先して比較してください。長時間の転送が主な用途なら、継続時の速度、接続先サーバーの制限、バッテリー消費も確認しましょう。

接続がタイムアウトする場合は、まず現在のネットワークからUDPの接続先へ到達できるかを確認し、次にアドレス、ポート、認証情報を調べます。接続後に一部のコンテンツだけ読み込みが止まる場合は、帯域の見積もり、経路上のパケットサイズ、DNS、ルールを確認してください。ネットワークを切り替えると、実際の経路条件が変わることがあります。プロトコルに該当機能があっても、すでに行われているすべての通信が中断しないとは限りません。接続開始時、ネットワーク切り替え時、長時間転送時のどの段階で失敗したかを記録し、症状に合わせて次を確認してください。帯域の値を際限なく大きくするのは避けましょう。

8. 用途に合わせて選び、階層ごとに確認する

まず既存の条件から候補を絞る

利用できる接続先がひとつだけなら、すべてのプロトコルから選び直すのではなく、正しくインポートして動作を確認することが先決です。既存サービスで複数の組み合わせが提供されている場合は、現在のネットワークで利用できない種類を除外してから、実際の用途で比較します。Wi-Fiとモバイル回線を頻繁に切り替えるなら、復旧までの時間や失敗の回数を確認します。自分で管理するネットワークのリソースにアクセスする場合は、アドレス範囲、DNS、アクセス権を確認します。短いリクエストが多い用途では接続確立と最初の応答を、継続的な転送では安定したスループットを重視してください。

できるだけ同じ端末、同じネットワーク、同じ接続先のコンテンツを使い、初回接続、再アクセス、一定時間経過後の状態をそれぞれ確認してください。一度に変更するのは項目ひとつ、または設定ひとつだけにします。プロトコル、DNS、Global Routingを同時に変更しないでください。Connectivity Testは接続先の状態を簡易的に確認するために使えますが、テストの数値はウェブページ全体の読み込み時間と同じではなく、すべての接続先を代表するものでもありません。詳しくは遅延、地域、プロトコルの選び方をご覧ください。

最小限のルールで通信経路を確認する

現在のGlobal RoutingがConfigの場合、ルールの順番によってリクエストの経路が変わります。以下は構文の説明であり、既存の設定を置き換える完成済みの設定ではありません。example.comは例として使用しています。PROXYが指す実際のポリシーは現在の設定に合わせてください。ルールは通常、上から順に照合され、前のルールに一致しなかった場合はFINALが最後の処理を担います。サーバーの設定が正しくても、接続先が先にDIRECTまたはREJECTに一致すると、想定と異なる動作に見えることがあります。

[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アドレスの地理情報データベースをもとに判定するもので、ウェブサイトの言語を見ているわけではありません。DNSの結果、接続先がドメイン名として扱われるかどうか、前のルールの内容も最終的な一致に影響します。例にある地域ルールを、すべての利用者に適した選択と考えないでください。プロトコルをテストする場合は、まず接続先にどの経路を使うべきかを決め、ログに記録された実際の処理を確認します。直接接続をテストした結果を、2つのプロトコルの比較と取り違えないようにしてください。

接続先から目的地まで段階的に確認する

第1段階では端末のネットワークが正常か確認し、次に接続先のドメイン名、アドレス、ポートを調べます。第2段階ではプロトコル、認証、転送方式を確認します。第3段階ではTLSの名前、証明書、時刻の条件を調べます。第4段階ではGlobal Routing、ルール、DNSを確認し、最後に目的の接続先とサーバー側のアクセス権を調べます。特定のネットワークだけで失敗する場合は、そのネットワークの到達性と転送条件を優先して比較してください。どのネットワークでも失敗する場合は、端末の各設定を別々に変更するより、接続先の状態や共通する設定を確認しましょう。

サブスクリプションの更新後に項目が消えたり設定が変わったりした場合は、インポート時の解析で問題が起きたのか、既存項目の接続で問題が起きたのかを切り分けてください。リストが空になったからといって、暗号化方式の選択が原因とは限らず、TLS設定の変更で解決するものでもありません。サブスクリプションをインポートできない、またはリストが空になる場合の確認方法を参考に、リンクの完全性、利用中のサービスの状態、更新のタイミングを確認してください。サブスクリプションのURLには機密情報が含まれる場合があります。問題を共有する際、そのまま公開しないでください。

復元できる設定と有効な記録を残す

テストのたびに、ネットワークの種類、プロトコルの組み合わせ、変更した項目、結果を記録してください。認証情報をすべて公開する必要はありません。秘密鍵、パスワード、UUID、サブスクリプションの完全なURLをスクリーンショットに含めないでください。エラーメッセージに機密情報が含まれていないかも確認しましょう。効果のない変更は元に戻し、設定が重なった状態を残さないでください。操作手順に戻る場合は使い方ガイド、症状から調べる場合はよくある質問をご覧ください。画面の用語やキーワードは用語集で確認できます。

最終的な判断基準は、利用中のサーバー設定と一致していること、現在のネットワークで安定して使えること、必要なアプリの通信を正しく処理できること、設定の内容を把握して管理できることです。一度のテストで良い結果を得るために証明書の検証を犠牲にしたり、複雑な設定を必ず優れたものと考えたりしないでください。再現と復元ができる正しい基準をまず用意し、具体的なボトルネックを調整することで、プロトコル設計の特徴とネットワーク環境の違いを切り分けられます。