VPNプロトコルと回線技術リファレンス

プロトコルは速度ランクではない

プロトコルはデータのカプセル化、セッション確立、接続状態の確認方法、パケットロス時の復旧方法を決めます。ハンドシェイク、CPU使用率、メモリ配分、再接続の間隔、ネットワーク切り替え後の復旧性に影響しますが、プロトコル名そのものが速度を保証するわけではありません。同じプロトコルでも回線が違えば結果は大きく変わり、同じ品質の回線なら異なるプロトコルでも日常利用に十分な場合があります。プロトコルを単純な「速さランキング」にすると、体感を左右する経路品質を見落としがちです。

選定時はまず利用するサービスの挙動を確認します。ウェブやテキストメッセージは短い接続が多く、初回表示のスムーズさが気になります。ファイル転送や高画質動画は継続的な通信のため、安定したスループットと長時間のパケットロスからの復旧が重要です。音声通話、会議、リモートデスクトップはジッターに敏感で、平均速度が高くても音声や映像の瞬断は防げません。プロトコルは用途に合わせるものであり、流行の名称に用途を合わせるものではありません。

回線がデータの実際の経路を決める

回線トポロジーは、入口、中継点、出口の関係を示します。直結では現在のネットワークから出口へ直接アクセスするため経路はシンプルですが、通信事業者の方針や時間帯によってルートが変わることがあります。中継では、近い、または相互接続に優れた入口へ接続してから、サービス側で目的の出口へ転送します。これにより、制御しにくい公衆ネットワーク区間を減らせます。専用線は中間リンクの管理性をさらに重視し、経路の安定と輻輳の分離を目的としますが、すべての端末で同じ低遅延になるわけではありません。

接続が遅いとき、すぐにプロトコルを変えるのは避けましょう。同じ出口で複数のプロトコルが似た状態なら、入口、経路、出口の負荷を優先して疑います。特定のプロトコルだけが頻繁に再接続し、他は安定している場合は、そのプロトコルと現在のネットワークの互換性を確認します。この順番なら無効な切り替えを減らし、回線の問題をクライアントのせいにすることも避けられます。

端末環境が最終的な結果を変える

デスクトップOSは通常、接続プロセスを継続して実行でき、電源管理も比較的緩やかです。モバイルOSではバックグラウンド処理が停止されたり、Wi-Fiとモバイルネットワークが切り替わったり、画面オフ後に通信処理が再調整されたりします。デスクトップで安定する回線でも、モバイル端末をロックした後に同じ状態が続くとは限りません。クライアントの実装、システムのネットワーク拡張、バックグラウンド権限、省電力設定が接続のライフサイクルに関係します。

基準を作るときは、端末、プロトコル、用途を固定し、条件を一つだけ変えます。たとえば同じネットワークでプロトコルを比較し、次にプロトコルを固定して回線を比較し、最後にフォアグラウンドとバックグラウンドを切り替えて確認します。プロトコル、ノード、ネットワーク、クライアントを一度に変えると、多く試したように見えても、改善の原因を特定できません。技術選定には再現性が必要で、偶然の一度の成功に頼るべきではありません。

Shadowsocks：構造はシンプル、回線品質に左右される

Shadowsocksは、軽量な暗号化転送として理解すると分かりやすいプロトコルです。構造が比較的シンプルで、クライアントとサーバーの実装も広く普及しており、リソース使用量を管理しやすい傾向があります。ウェブ、メッセージ、開発ツール、通常のダウンロードに適した基本的な選択肢です。ただし、回線の輻輳を修復したり、公衆ネットワーク上のジッターを自動的に解消したりはしません。基盤回線が安定していれば余分な処理を抑えられますが、継続的なパケットロスがあるとアプリケーション側でも停止を感じます。

Shadowsocksを使うときは、暗号方式の名称だけでなく、クライアントがシステムプロキシ、DNS、接続の再利用を正しく処理しているかを確認します。アプリによってはシステムプロキシに従わず、独自に名前解決結果をキャッシュすることもあります。そのため「ブラウザーは使えるがアプリは使えない」という差が生じます。この場合、ノードを変え続けるより、通信が本当にクライアントへ入っているかを確認することが重要です。

VMess：状態情報が豊富で、設定項目が多い

VMessは比較的豊富なセッション情報と認証情報を持ち、一般的な実装では複数の伝送方式と組み合わせられます。既存のサービス構成との互換性が必要な環境に向いている一方、設定の範囲が広く、クライアントとサーバーのパラメーターを一致させる必要があります。伝送方式、暗号化、安全層、パスのいずれか一つでも異なると、単なる速度低下ではなくハンドシェイク失敗として現れることがあります。

VMessを切り分けるときは、認証、伝送方式、外側のセキュリティを分けて確認します。サブスクリプションのインポートでは通常これらのパラメーターが自動設定されるため、手動で書き換えたものと混在させるのは避けてください。インポート後に接続できない場合は、まずサブスクリプションを再取得し、クライアントで正しい項目が選ばれていることを確認します。その後、システム時刻、DNS、ネットワーク権限を確認します。設定項目が多いからといって性能が必ず高いわけではなく、異なる構成に対応するためのツールボックスと考えるとよいでしょう。

Trojan：標準的なセキュアセッションを利用し、境界が明確

Trojanは通常TLSセッション上で動作し、認証と暗号化の境界を理解しやすい構成です。標準的なセキュリティ層と成熟したネットワークライブラリが必要な用途に適しています。接続確立時には安全なハンドシェイクが行われるため、初回接続の体感は名前解決、証明書検証、ネットワーク往復の影響を受けます。セッションが安定した後の継続通信は、主に回線容量、輻輳、出口によって決まります。

デスクワーク、ブラウザーアクセス、継続接続に向いており、アプリとの互換性が求められる環境でもよく使われます。特定のネットワークで長時間接続が安定しない場合は、同じノードの別プロトコルと比較します。TCPベースのプロトコルがすべて似たように停止するなら、原因はTrojan自体よりもパケットロスからの復旧や回線の輻輳にある可能性が高いでしょう。

VLESS：プロトコル内の冗長性を抑え、組み合わせの正確さに依存

VLESSは認証と具体的な安全な伝送方式を分離し、プロトコル自体をシンプルに保っています。TLSなどの安全層と組み合わせて使われることが多く、性能特性は伝送方式から切り離して語れません。同じVLESSという名称でも、組み合わせる伝送方式や回線によって接続確立やリソース使用量は大きく変わります。サブスクリプション内のVLESS項目は、単独の速度保証ではなく、複数要素を組み合わせる入口として理解してください。

この分離構造は導入要件に応じた組み合わせを容易にしますが、クライアントがサブスクリプションのパラメーターを完全に理解している必要があります。クライアントを更新するかサブスクリプションを再インポートするほうが、設定項目を手動で一部コピーするより確実な場合が多いです。「接続は確立するがアプリに通信がない」ときは、接続ボタンを繰り返し押すのではなく、ルーティングルール、DNS、システムのネットワーク拡張を確認します。

Hysteria2とTUIC：不安定な経路向けのUDP方式

Hysteria2とTUICはいずれもQUICとUDPの伝送能力を基盤とし、「常に速い」ことではなく、ジッター、パケットロス、ネットワーク切り替えに対して、従来のTCPとは異なる輻輳制御と多重化を行う点が特徴です。基盤でUDPが利用でき、経路品質の変動が大きく、アプリケーションが継続通信を必要とする環境に向いています。現在のネットワークがUDPを制限している場合や、端末でバックグラウンドのUDP接続が厳しく制御されている場合、接続が劣化したり確立できなかったりします。

どちらもクライアントの実装品質を確認する必要があります。輻輳制御、接続移行、タスクスケジューリング、システムインターフェースの呼び出しが実際の体感に影響します。モバイル端末では、フォアグラウンドで一度ダウンロードするだけでなく、待機からの復帰と消費電力も確認してください。プロトコルに変動へ対応する能力があっても、出口容量の不足を解消できるわけではありません。ピーク時に出口が飽和しているなら、UDP方式へ変えても復旧方法が変わるだけで、利用可能な帯域が増えるわけではありません。

接続確立の速さはコールドスタートと再利用を分けて見る

ユーザーが感じる「接続が速い」には、少なくともいくつかの段階があります。ドメイン名の解決、入口へのネットワーク接続、プロトコル認証、外側の安全なハンドシェイク、システムのネットワークインターフェースの引き継ぎ、アプリケーションによるリクエストの再送です。コールドスタートでは全工程を経ますが、既存接続の再利用では一部を省けることがあります。クライアントのボタンが接続済みになっただけでは、業務通信が通ったとは限りません。新しいウェブページを開くか、アプリでリクエストを再送し、名前解決とルーティングも切り替わったことを確認してください。

短時間のテストでは、接続再利用の結果に偏りやすくなります。あるプロトコルの2回目の接続が明らかに速くても、名前解決キャッシュ、セッションキャッシュ、またはシステムのネットワークインターフェースがまだ解放されていないだけかもしれません。公平に比較するには、同じネットワーク、同じ入口、同じ出口で行い、初回接続か復旧接続かを記録します。ミリ秒単位の順位を求める必要はなく、安定しているか、特定の段階で頻繁に止まるかに注目するほうが有益です。

リソース使用量は暗号化、コピー、スケジューリングから生じる

CPU消費量は暗号アルゴリズムだけで決まりません。アプリケーション、システムのネットワーク拡張、クライアントコアの間でデータがコピーされること、接続数の増加、多重化キューの拡大、ログレベルの上げすぎなども追加処理を生みます。メモリ使用量はバッファー、同時接続数、キャッシュ戦略の影響も受けます。軽量なプロトコルはリソース使用量を予測しやすい傾向がありますが、クライアントの実装が頻繁にウェイクアップしたり大量の接続を維持したりすると、軽量な構造でも消費電力が目立つことがあります。

リソースを観察するときは、一時的なピークだけを見ないでください。ウェブページを開いた直後の短時間の計算は通常の動作です。より重要なのは、通信がないときもウェイクアップが続くか、画面ロック後も長時間アクティブか、ネットワーク切り替え後に重複した接続が残るかです。デスクトップではタスクマネージャーやシステムのアクティビティ監視ツールを使い、モバイルではシステムのバッテリー画面、バックグラウンド活動の記録、実際の待機中の変化を合わせて判断します。

パケットロスからの復旧は単純な再送速度ではない

従来のTCPは接続ごとに順序付きバイトストリームを管理します。失われたデータを復旧するまで、後続の内容を順番どおりアプリケーションへ渡せません。QUICはストリームの構成と復旧に異なる仕組みを持ち、互いに関係しないリクエスト間の待ち合わせを減らせる場合があります。ただし、基盤の帯域と出口負荷は変えられません。経路が継続的に輻輳しているなら、どのプロトコルでも送信ペースを下げる必要があり、そうしなければ再送を増やすだけです。

したがってプロトコルを選ぶときは、「いま問題になっているのはどの待ち時間か」と考えます。ウェブの初回表示が遅いなら名前解決やハンドシェイク、動画が周期的にバッファリングするならスループットの変動、会議の音声が途切れるならジッターやリアルタイムパケットの損失、ダウンロード速度が徐々に落ちるなら輻輳制御によるウィンドウ縮小が考えられます。問題を明確に定義するほど、プロトコル比較の価値は高まります。

直結：経路は短いが、公衆ネットワークの変化を受けやすい

直結とは、端末が接続しているネットワークから出口ノードへ直接アクセスすることです。途中で通信事業者や相互接続ネットワークを通る点は変わりませんが、サービス側の入口を追加で経由しません。構造がシンプルで、余分な中継処理がないことが利点です。相互接続が良好なら、接続確立も継続通信もスムーズになります。一方、制御できる経路の範囲が小さく、通信事業者のルート変更、ネットワーク間接続の輻輳、遠距離の公衆ネットワークの変動が、そのまま接続に反映されます。

直結は、現在地から目的の出口まで良好なルートがある場合に適しています。判断は地図上の距離ではなく、継続接続が安定しているか、時間帯を変えても同じ問題が起きるか、複数のプロトコルが同時に影響を受けるかで行います。地理的に近い出口でもネットワークの経由数が少ないとは限らず、やや遠くても相互接続が明確な出口のほうが安定することがあります。

中継：制御しやすい入口で予測しにくい区間を短縮

中継回線では、まず端末から適切な入口へ接続し、その入口から出口へデータを転送します。変化しやすい公衆ネットワーク経路を、サービス側で調整できるリンクに置き換えることが目的です。通信事業者をまたぐ経路、遠距離の出口、ピーク時の変動に有効な場合がありますが、中継自体が処理工程を増やすため、入口の位置、入口容量、転送方針、出口品質のすべてが重要です。

中継が常に低遅延になるわけではありません。端末から入口まで遠回りしていたり、入口がすでに混雑していたりすると、転送区間が増えて待ち時間が長くなることもあります。現在のネットワークに合わせて入口を選び、特定のラベルが必ず速いと決めつけないことが大切です。H5VPNは120か国以上 / 190以上の回線をカバーしています。グローバルノードページで地域、都市、回線タイプを確認し、実際の用途に合わせて選んでください。

専用線：中間リンクの安定性と分離を重視

専用線系トポロジーの主な価値は、中間経路を管理しやすくし、通常の公衆ネットワーク通信と制御しにくいリンクを共用する状況を減らせることです。IEPLなどのラベルは回線の構成方式を示すもので、端末から入口までの全経路が固定されているという意味ではありません。ユーザー側の接続ネットワーク、無線品質、家庭用ルーターの状態、最後の通信事業者区間も結果に影響します。

専用線は、会議、リモートデスクトップ、長時間のファイル転送、安定したビットレートでの再生など、継続的な安定性が重要な負荷に向いています。判断の焦点は、瞬間的な速度のピークではなく、変動が収束しているかどうかです。ピーク速度が高くても頻繁に低下する回線は、ピーク速度が普通でも安定している回線よりリアルタイム用途に向くとは限りません。

入口、出口、目的のサービスを分けて特定する

入口は端末からの接続を受け、出口は外部へのアクセスを担います。目的のサービスには独自の接続方針やコンテンツの地域分けがあります。クライアントに接続済みと表示されても、端末からサービスまでの経路が確立したことを示すだけで、特定のサービスが必ず正常に応答するとは限りません。複数のウェブサイトは正常で一つのサービスだけ異常なら、目的のサービス、DNS、出口との相性を確認します。すべての通信が同時に止まるなら、入口、端末ネットワーク、接続コアの問題である可能性が高いでしょう。

回線を選ぶときは代替経路を残します。よく使う出口に直結と中継の2案を用意し、仕事用と娯楽用で異なる出口を使う方法もあります。頻繁に切り替えるためではなく、障害の切り分けを速くするためです。代替経路が正常なら、端末の基本設定はおおむね有効だと考えられます。すべての経路で異常が出るなら、システム権限、クライアントの状態、ローカルネットワークの確認に戻ります。

パケットロスは用途によって異なる症状を見せる

パケットが失われると、信頼性を重視する通信では再送が必要になり、リアルタイム通信では期限切れのデータをそのまま破棄することがあります。ウェブでは、あるリソースだけ長時間待たされ、その後ページが突然表示されることがあります。動画ではバッファーが徐々に減り、画質低下や一時停止が起きます。会議では音声の欠落、映像の停止、操作の遅延が現れやすく、リモートデスクトップでは入力が送信された後、画面の反映が遅れることがあります。

これらを単に「遅い」とまとめることはできません。ダウンロードはバッファーと再送によって短時間のパケットロスを隠せますが、リアルタイム通信は期限切れのデータを待てません。会議に適した回線か判断するには、大容量ファイルを一度ダウンロードするのではなく、連続した会話と操作への反応を観察します。逆に、ウェブがスムーズに開いても、継続通信に十分な容量があるとは限りません。

ジッターは時間軸上の遅延の不安定さ

平均遅延が同じ2本の回線でも、一方が速くなったり明らかに停止したりするなら、操作体験は悪化します。アプリは再生を滑らかにするためバッファーを設けますが、バッファーが大きいほどリアルタイム性は下がります。音声通話やリモート操作ではバッファーを無限に増やせないため、ジッターの影響を特に受けます。プロトコルは送信や復旧の方針を調整できますが、基盤のキューが突然増えて生じる待ち時間を完全に消すことはできません。

無線環境そのものがジッターを生むこともあります。電波の競合、ローミング、ルーターのキュー、他の端末によるアップロードが、端末から入口までの最初の区間を不安定にします。この場合、遠隔地の出口を変えてもローカル側の待ち行列は解決しません。まずアップロードを使う処理を止め、アクセスポイントに近づくか有線ネットワークへ切り替え、ローカル区間が安定してから回線を比較してください。

ピーク時の問題は共有リソースの競合であることが多い

ピーク時には複数の経路で同時に利用量が増えます。家庭の接続、通信事業者間の相互接続、入口、中継、出口のいずれにもキューが生じます。キューが短いうちは遅延が増えるだけですが、増え続けるとパケットロスと輻輳制御の縮小が起こり、最終的にスループット低下と繰り返しのバッファリングとして現れます。速度測定の一時的なピークだけでは、時間全体の安定性は分かりません。短いテストがたまたま輻輳の時間帯を避けている可能性があるためです。

ピーク時の問題を特定するときは、同じ用途を維持しながら、同じ地域の回線、異なるトポロジー、近隣の出口を順番に変えます。特定の入口だけ異常なら同じ出口の別入口を試し、同じ地域の出口全体が異常なら近隣地域と比較します。遠隔地の回線がすべて同時に悪化するなら、ローカル接続と通信事業者の経路を確認します。目的はすべてのノードを無秩序に試すことではなく、障害範囲を絞ることです。

帯域、遅延、安定性は互いに代替できない

帯域は単位時間あたりに転送できるデータ量、遅延はリクエスト往復の待ち時間、安定性はこれらの指標が継続的に予測可能かどうかを示します。大容量ファイルは帯域に、インタラクティブなアプリは遅延に、会議や動画は安定性にも依存します。回線を選ぶときは、ウェブの初回表示待ち、動画の画質低下、会議の音声切れ、ダウンロード時間の増加のうち、どの失敗が最も許容できないかを先に決めます。

ストリーミングで画質が自動的に下がる場合は、4K視聴におすすめのVPN：画質が480pに落ち続ける原因と選び方を実測もご覧ください。ビットレート、バッファー、パケットロスの観点から画質変化を解説しています。本ページでは一般的なネットワーク層を扱い、特定のストリーミングサービスの結果をすべての用途に当てはめません。

WindowsとmacOS：継続実行の状態を確認しやすい

デスクトップOSでは通常、ネットワーク拡張とクライアントコアを継続して動かせるため、長時間のファイル転送、会議、開発環境に適しています。Windowsではシステムプロキシと仮想ネットワークモードの違いに注意します。システムプロキシだけを読むアプリもあれば、仮想ネットワークインターフェースの引き継ぎが必要なアプリもあります。macOSではネットワーク拡張に正しい権限を与える必要があります。権限設定が完了していないと、クライアント画面を操作できても、システム通信が接続に入らないことがあります。

デスクトップでは、タスクマネージャー、アクティビティ監視、システムのネットワーク設定を利用して切り分けます。一時的なCPU値を追うのではなく、アイドル時も継続的に使用しているか、ネットワーク切り替え後に接続を重複作成していないか、スリープ復帰後に手動再接続が必要かを確認します。macOSのインストールと権限設定は、macOS VPN入門：インストール、許可設定、サブスクリプションのインポートまでを参照してください。

iOSとAndroid：バックグラウンド停止とネットワーク切り替えが重要

モバイルOSは、フォアグラウンド／バックグラウンドの状態、電源管理、ネットワーク条件に応じてアプリを制御します。画面をオフにすると、クライアントはデスクトップのように動作し続けるとは限りません。Wi-Fiからモバイルネットワークへ切り替わると、既存接続のローカルアドレスと経路も変化します。接続移行に対応したプロトコルは早く復旧できる場合がありますが、最終的にはクライアントがシステムイベントを正しく受け取り、OSが必要なバックグラウンド処理を許可するかどうかに左右されます。

消費電力を判断するときは、通常の通信と異常なウェイクアップを分けて考えます。動画視聴やファイル同期では、暗号化とデータ送受信に継続的なリソースが必要です。一方、通信がないのに頻繁に動作する、画面ロック後も端末が発熱する、ネットワーク切り替え後に再試行を繰り返す場合は確認が必要です。まずサブスクリプションを更新し、詳細ログを停止し、不要な同時処理を閉じてから別のプロトコルと比較します。特定の回線だけで再接続が続くなら、プロトコルの計算量より回線の到達性を疑うべきです。

Linux：透過ルーティングと権限の境界を明確にする

Linuxは環境差が大きく、デスクトップディストリビューション、サーバー、コンテナではネットワーク管理方式が異なります。システムプロキシを使う場合、プロキシ設定に従うアプリだけが接続を通ります。仮想ネットワークインターフェースや透過ルーティングを使う場合は、権限、ルーティングテーブル、DNSを正しく設定する必要があります。接続後にコマンドラインツールだけが異常なら、そのツールが環境変数を読むか確認します。システム全体が異常なら、デフォルトルートと名前解決の経路を確認します。

複数のネットワーク管理ツールに、互いに競合するルールを同時に書き込まないでください。一時的なテストが終わったら、古いルートと古いDNSが復元されていることを確認します。長時間稼働する端末では、スリープ、ネットワークカードの再接続、サービス再起動後の復旧も観察します。プロトコルコアが正常でも、システムの起動順序や権限が正しいとは限りません。

複数端末でも同じ設定をそのまま複製しない

H5VPNはWindows / macOS / iOS / Android / Linuxに対応し、接続台数に制限はありません。同じサブスクリプションを異なる端末で使えますが、端末の特性に合わせて接続方式を選ぶ必要があります。デスクトップでは安定した継続実行、モバイルでは画面ロック後の復旧と電池消費、Linuxではシステムプロキシと透過ルーティングの境界を確認します。デスクトップ向けの複雑なルールをそのままモバイルへ移すと、デバッグの負担が増えがちです。

サブスクリプションリンクはアカウントの認証情報にあたるため、信頼できるクライアントだけにインポートし、安全に保管してください。登録にメールアドレスは不要で、ユーザー名とパスワードだけで完了します。クライアントやサブスクリプションを再取得する場合はユーザーパネルへ進み、チャット履歴でリンクを何度も転送しないでください。クライアントのダウンロードはユーザーパネルから行えます。

ウェブ、情報検索、AIツール

この用途では短いリクエストが多く、ストリーミング形式の応答を維持することもあります。初回表示は名前解決とハンドシェイクに左右され、連続した会話では接続の安定性が求められます。まずは構造がシンプルで互換性の成熟したShadowsocksまたはTrojanを、経路が明確な中継回線や専用線と組み合わせて試します。現在のネットワークでTCPのジッターが目立つなら、Hysteria2やTUICも比較し、ストリーミング応答の中断が減るか確認します。

トップページが開くかどうかだけで判断しないでください。ログイン、新しいリクエストの送信、一定時間の連続出力、ブラウザータブの切り替えと復帰まで確認します。ページは開くのにストリーミング応答が頻繁に止まるなら、長時間接続と回線のジッターを確認します。特定のツールだけ異常で他のウェブサイトが正常なら、出口地域、DNS、そのサービス自体の状態を確認します。プロトコルの切り替えは、これらの確認の後に行います。

動画、ライブ配信、大容量ファイル転送

継続通信には十分なスループットと、輻輳時に滑らかに復旧する性能が必要です。回線容量が十分でパケットロスが少なければ、複数のプロトコルが正常に動作します。経路の変動が大きい場合は、QUICベースの方式が変化に対応しやすいことがありますが、UDPが利用でき、クライアント実装が安定していることが前提です。直結回線が長時間安定しているなら、一般的なラベルだからといって複雑な構成へ無理に変える必要はありません。

確認時は再生開始だけでなく、連続再生、シーク、画質の復旧を観察します。ダウンロードでは速度が安定しているか、一時停止後に復旧できるか、他のアプリを同時に使ったときに明らかな競合が起きるかを確認します。ストリーミングサービスへアクセスできるかどうかは出口との相性にも左右されるため、ネットワーク層が安定していても、すべてのコンテンツライブラリが同じとは限りません。ノードページには回線タイプとストリーミング対応が表示されます。選ぶ前にグローバルノードを確認してください。

会議、音声通話、リモートデスクトップ

リアルタイム通信が最も苦手とするのはジッターと連続的なパケットロスです。まず経路が安定した中継回線や専用線を選び、その後にプロトコルを比較します。TrojanやVLESSなどTCPベースの構成でも、安定した回線なら良好な体験を維持できます。ローカルネットワークの切り替えが多い、または経路のパケットロスが目立つ場合はTUICやHysteria2を試せますが、マイク、画面共有、リモート入力を実際に確認し、ダウンロード速度で代用しないでください。

会議前にクライアントを急に更新したり、ルールを大幅に変更したりするのは避けます。現在の経路に異常が出たとき、すぐ切り替えられる検証済みの代替回線を用意してください。音声が途切れても映像が続くなら、リアルタイムパケットがジッターの影響を受けている可能性があります。すべてが同時に停止するなら、ローカルネットワークと入口を確認します。リモートデスクトップの入力だけが遅いなら、接続先ホストとアプリ自体を確認します。症状によって確認すべき層は異なります。

短期出張とホテルのネットワーク

ホテル、コワーキングスペース、公衆Wi-Fiでは接続方式が異なり、ウェブ認証が必要な場合や、端末のスリープ後に再認証を求められる場合があります。まず接続ネットワーク自体の認証を完了し、その後にクライアントを起動します。認証ページが表示されない場合は、いったん接続を切り、通常のウェブページを開き直してシステムに認証ページを表示させます。完了後に接続を再開してください。

出張では復旧性能と予備経路を重視します。デスクトップとモバイルのクライアントを用意し、サブスクリプションを事前にインポートして、出発前に利用できることを確認してください。ホテルのネットワークがUDPとの互換性に乏しい場合は、Shadowsocks、Trojan、VLESSの適切な項目へ切り替えます。TCP経路が混雑している場合は、中継とQUIC方式を比較します。詳しいケースは出張におすすめのVPN：短期プランとホテル回線を実測比較をご覧ください。

プランは利用状況に合わせて選ぶ

プロトコルと回線が接続方式を決め、プランが利用できるデータ量を決めます。月額プランは ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBを含み、通信量は開通日を基準に毎月リセットされます。途中でアップグレードする場合、差額は残り日数に応じて計算されます。データパックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、有効期限はありません。

動画の継続視聴や大容量ファイル転送には月額プランで使用量を見積もる方法が適しています。断続的な出張や低頻度の予備用途ではデータパックと比較してください。いずれも実際の用途に基づいて選べばよく、特定のプロトコルを使うために別の端末枠を購入する必要はありません。本サービスは接続台数無制限で、14日間の無条件返金にも対応しています。詳細なルールと支払い方法は料金プランページで確認できます。Alipay / WeChat Pay / USDTに対応しています。

まず障害の範囲を確認する

最初に行うのは、すべての設定を切り替えることではなく、影響範囲を判断することです。単一のウェブサイト、単一のアプリ、特定の用途、すべての通信のどれが異常なのかを確認します。ブラウザーは正常でデスクトップアプリだけ異常なら、通常はシステムプロキシやアプリのルーティングが関係します。複数のアプリが同時に異常なら、接続コア、ネットワークインターフェース、入口を確認します。特定の対象だけ異常なら、目的のサービス、出口地域、DNSを優先して確認します。

次に、問題が時間、ネットワーク、端末のどれに関係するかを確認します。同じ端末がネットワークを変えると復旧するなら、元の接続環境を調べます。同じネットワーク上の複数端末で異常が出るなら、ローカルルーターや上流経路に共通の問題がある可能性があります。モバイル端末が画面ロック後だけ切断されるなら、バックグラウンド方針を確認します。範囲を絞ることで、すべての障害をノードの利用不可として扱わずに済みます。

再現可能なテスト基準を作る

普段使う端末、安定した接続ネットワーク、既知の利用可能なノード、明確な用途を基準にします。プロトコル、回線タイプ、出口地域、クライアントモード、異常の状態を記録します。その後は各回でプロトコル、回線、ネットワークのいずれか一つだけを変えます。変更後に復旧したら元の条件へ戻して再テストし、キャッシュや一時的な変動ではないことを確認します。

複雑な監視環境は必要なく、短いテキスト記録で十分です。記録すると各回を比較でき、問い合わせ時にも状況を説明しやすくなります。以下は例で、サブスクリプションの認証情報や実際のアドレスは含みません。

環境: macOS
用途: ビデオ会議
プロトコル: Trojan
トポロジー: 中継
現象: 接続は確立するが、通話を続けると断続的に停止する
比較: 同じ出口で専用線に切り替えると復旧
再テスト: 元の回線に戻すと問題が再発

層ごとに置き換えて確認する

まず同じ出口でプロトコルを変え、伝送の互換性を判断します。次にプロトコルを固定して同じ地域の回線を変え、入口と経路を確認します。その後で出口地域を変え、出口の負荷や目的のサービスとの相性を切り分けます。すべての組み合わせで失敗する場合は、クライアントの権限、サブスクリプションの更新状態、システム時刻、DNS、ローカルネットワーク、セキュリティソフトのルールを確認します。

Hysteria2とTUICで接続できない場合は、まず同じノードのTCP系プロトコルを試します。TCP系は正常でUDP系だけが継続的に失敗するなら、現在のネットワークでUDPが利用できるかをさらに確認します。UDPで接続できてもモバイル端末の画面ロック後に頻繁に復旧するなら、システムのバックグラウンド方針とクライアント実装を確認します。プロトコルのラベルだけでサーバー側の障害と判断しないでください。

接続状態とサービス利用可否を分けて考える

クライアントに接続済みと表示されるのは、トンネルまたはプロキシセッションが確立したことを示します。しかし実際のリクエストはDNS、ルーティング、出口、目的のサービスを通過する必要があります。確認時はリクエストを新しく送信し、古い接続を使い続けているページを更新するだけにしないでください。ブラウザーは既存接続を再利用し、アプリは名前解決結果をキャッシュすることがあります。関連アプリを完全に終了して再起動すると、新しい回線が引き継いだかをより明確に確認できます。

新しいウェブページは正常なのに古いタブだけ異常なら、古い接続が移行していない可能性があります。ドメインを解決できないのに直接の業務接続は正常ならDNSを確認します。ページの一部だけ読み込まれるなら、パケットロス、ルール、配信ドメインを確認します。しばらくしてから停止するなら、ネットワーク切り替え、セッション維持、バックグラウンド停止を確認します。「使えない」を具体的な段階に分けると、トラブルシューティングは大幅に速くなります。

問い合わせを送るタイミング

基本的な比較を終えても原因を特定できない場合は、ユーザーパネルから問い合わせを送信します。端末プラットフォーム、クライアントモード、プロトコル、回線タイプ、出口地域、接続ネットワークの種類、発生時間帯、再現手順を記載してください。パスワード、サブスクリプションリンク、その他の認証情報は送らないでください。「遅い」という一般的な説明より、条件を比較した結果のほうが原因を特定しやすくなります。

問い合わせ窓口はユーザーパネルにあります。基本設定が済んでいない場合は、初心者ガイドに戻り、インストール、権限、サブスクリプションのインポート、接続確認を順番に行ってください。回線を比較する場合はグローバルノードページを、月額プラン、データパック、アップグレードのルール、返金条件を確認する場合は料金プランページをご覧ください。