インストール前にサブスクリプション、クライアント、システム権限を確認
初回設定で混同しやすいのは、サブスクリプションサービス、クライアント、サーバーノードの3つです。サブスクリプションサービスは回線情報を提供し、クライアントはその情報を読み込んで該当する通信を制御します。ノードは、実際の接続で選択する入口と出口です。これらは同じものではありません。クライアントだけで有効なサブスクリプションがなければ、通常は利用可能な回線を取得できません。反対に、サブスクリプションURLだけで対応するクライアントがなければ、Windowsで接続を確立できません。
クライアントは、サービスの管理画面に用意されたダウンロードページから入手してください。検索結果だけを頼りに、名前が似たプログラムを無作為にダウンロードしたり、出所不明の改変版を使ったりしないでください。インストール前に、ファイルの発行元、デジタル署名、インストール先を確認しましょう。セキュリティソフトがネットワークドライバーや仮想ネットワークアダプターの変更を警告した場合は、まずクライアントの入手元を確認してから許可を判断します。システムの保護機能をいきなり無効にするのは避けてください。
Windowsのシステムプロキシだけを使い、仮想ネットワークアダプターを必要としないクライアントもあります。一方、TUNモードに対応し、ネットワークドライバーのインストールと適切な権限を必要とするクライアントもあります。インストール中にドライバーの確認が表示されても、必ずしも異常とは限りません。ただし、選択したクライアントの機能説明と一致している必要があります。会社が管理する端末では、ドライバーのインストール、プロキシ変更、自動起動が制限される場合があるため、組織のネットワークおよび端末管理ルールに従ってください。
Windowsの日付、時刻、タイムゾーンが正しいことも確認してください。TrojanやVLESSはTLSと組み合わせて使われることが多く、システム時刻のずれによって証明書の検証に失敗する場合があります。証明書エラーが出たときは、検証を無効にして回避するのではなく、まず時刻を合わせ、サブスクリプションを更新し、回線情報を確認するほうが原因を特定しやすくなります。
クライアントをインストールしてサブスクリプションを正しく追加
ユーザーパネルからクライアントを入手したら、インストーラーの手順に従ってセットアップします。初回起動時は、いきなりグローバルプロキシを有効にせず、サブスクリプション管理、設定管理、リモート設定などの項目があるか確認してください。クライアントによって名称は異なりますが、基本的な流れは同じです。サブスクリプションURLを読み込み、ノード一覧を取得し、クライアントが認識できる設定に変換します。
おすすめの追加手順
- サービスの管理画面でサブスクリプションURLをコピーします。手動選択によるコピー漏れや余分な空白を避けてください。
- クライアントのサブスクリプション管理画面を開き、クリップボードからの追加またはリモートサブスクリプションの追加を選択します。
- サブスクリプションに識別しやすいローカル名を付けます。この名前はクライアント内で設定を区別するためだけのもので、サーバー側の内容は変わりません。
- 更新を実行し、ノード一覧が表示されるまで待ちます。その後、プロトコル、地域、回線名が表示されているか確認します。
- 回線を1つ選んで接続テストを行い、利用できることを確認してから自動更新とスプリットトンネリングを設定します。
一部のクライアントでは、Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICの単独リンクを直接追加することもできます。単独設定は一時的な切り分けに向いていますが、日常利用ではサブスクリプションの追加がおすすめです。回線パラメーターが変わっても一括更新できるためです。リモートサブスクリプションと手動ノードを同時に保存する場合は、同名の項目に注意し、古い設定へ接続しないようにしてください。
サブスクリプションの更新に失敗したら、まず端末からサブスクリプションURLへアクセスできるか確認し、次にURLが途中で切れていないか確認します。チャットアプリによってはコピー時に句読点が追加され、ブラウザー拡張機能によってはクリップボードの内容が書き換えられることがあります。管理画面から再度コピーして構いませんが、完全なURLを公開検査サイトへ送信しないでください。認証情報が漏れた疑いがある場合は、古いURLを使い続けず、サービスの管理画面から更新してください。
QRコードは端末間で設定を移す場合に便利ですが、Windowsでは通常、サブスクリプションURLを直接コピーするほうが確認しやすいでしょう。クライアントに「サブスクリプション変換」機能がある場合は、サービス側が明確に対応している方法を優先してください。非公開のサブスクリプションを不明な変換サービスへ送ると、認証情報に触れる範囲が広がり、変換中にプロトコル項目が失われる可能性もあります。
プロトコルと回線タイプの選び方
プロトコルは、クライアントとノードがデータをどのようにカプセル化、暗号化、転送するかを決めるものです。回線タイプは、通信がどのようなネットワーク経路を通るかを示します。同じプロトコル名でも回線品質が同じとは限らず、似た回線名でもプロトコルの性能が一致するとは限りません。判断するときは、プロトコルの互換性、ネットワーク環境、回線経路を分けて考えましょう。
| プロトコル | 通信の特徴 | 選ぶときの確認点 |
|---|---|---|
| Shadowsocks | 構成が比較的シンプルで、共通鍵暗号によってプロキシ通信を保護します。 | クライアントが対応する暗号方式とプラグインパラメーターを確認します。 |
| VMess | 設定項目が多く、さまざまな転送方式やTLSと組み合わせて利用できます。 | 時刻、転送方式、ホスト名、パスをサーバー側と一致させる必要があります。 |
| Trojan | 通常はTLSで接続するため、証明書とドメインの検証に影響されやすい方式です。 | 証明書エラーを無視せず、まず時刻とサブスクリプションのパラメーターを確認します。 |
| VLESS | プロトコル自体は軽量で、安全性と通信性能は組み合わせる方式に左右されます。 | TLS、REALITY、その他の転送パラメーターにクライアントが対応しているか確認します。 |
| Hysteria2 | QUICとUDPをベースにし、複雑なネットワーク環境での輻輳制御を重視します。 | 利用中のネットワークがUDPを制限していると、接続状況が大きく変わる場合があります。 |
| TUIC | 同じくQUICとUDPをベースにし、並列転送と接続の復旧を重視します。 | クライアントのコア、サーバー側のパラメーター、UDP環境の互換性が必要です。 |
プロトコルを選ぶとき、名称が新しい方式を常に優先する必要はありません。クライアントのコアが非対応、パラメーターが不足、またはネットワークがUDPを制限している場合、理論上の機能は実際の快適さにつながりません。まずはサーバー側が推奨する設定を使うのが無難です。ウェブページは開けるのに、会議、ダウンロード、リモート協業で問題が出る場合は、互換性のある別のプロトコルと比較してみましょう。
直接接続、中継、IEPL専線の違い
直接接続回線は、通常、利用中のネットワークから海外のノードへ直接接続する方式です。経路はシンプルですが、利用中の通信事業者の国際出口や国際経路に左右されやすくなります。混雑時間帯の経路変更、迂回、パケットロスはいずれも通信品質に影響します。国内の国際出口が比較的安定していて、追加の転送を減らしたい場合に向いています。
中継回線では、まず近い入口へ接続し、その後中継ネットワークを経由して出口ノードへ向かいます。理想的でない公衆ネットワーク経路を避けることが目的ですが、最終的な結果は入口の品質、中継リンク、出口の状態に左右されます。中継が直接接続より必ず速いとは限らず、入口が遠い場合や経路が混雑している場合は遅くなることもあります。
IEPLは通常、国際イーサネット専線系の接続を指し、指定された接続拠点間で通信を運びます。サービス事業者が提供する実際の製品では、国内アクセス、中継、公衆ネットワークの出口を組み合わせる場合もあります。そのため、「IEPL」という名称だけで経路全体を判断することはできません。選択時は、回線の説明、対象地域、利用環境でのテストを組み合わせ、回線ラベルを固定速度の保証とみなさないでください。
システムプロキシとTUNモードの違い
Windowsクライアントでよく使われる通信の取り込み方法には、システムプロキシとTUNがあります。システムプロキシはWindowsのプロキシ設定を変更し、システムプロキシに従うアプリのリクエストをクライアントへ渡します。ブラウザーや多くのデスクトップアプリは利用できますが、一部のゲーム、コマンドラインプログラム、独立したアップデーター、独自のネットワークスタックを使うアプリはシステムプロキシを無視する場合があります。
TUNモードは仮想ネットワークインターフェースを通じて、より広範囲のIP通信を取り込みます。そのため、システムプロキシに対応しないプログラムでも扱いやすくなります。一方で設定は複雑になり、セキュリティソフト、仮想マシン、コンテナ、企業ネットワーククライアント、その他のネットワークドライバーと経路が競合する可能性があります。有効化後にシステム全体がネットワークへ接続できなくなったら、まずTUNを終了し、仮想ネットワークアダプター、ルート、DNSを確認してください。サブスクリプションを何度も再インストールするのは適切ではありません。
初めて使う場合は、まずシステムプロキシから始めるのがおすすめです。ウェブアクセスとサブスクリプション回線が正常だと確認してから、対象アプリがシステムプロキシに従わない場合にTUNを試します。これにより、「回線が利用できない」のか「通信が取り込まれていない」のかを切り分けられます。最初からシステムプロキシ、TUN、DNS、ファイアウォールを同時に変更すると、どの層が原因か判断しにくくなります。
| モード | 適した用途 | 主な制限 |
|---|---|---|
| システムプロキシ | ブラウザー、Windowsのプロキシ設定に従うデスクトップアプリ | 一部のプログラムはシステムプロキシを迂回します |
| TUNモード | より広範囲の通信を取り込みたいアプリ | 仮想ネットワークアダプター、ルート、セキュリティポリシーと競合する可能性があります |
| アプリ内プロキシ | 指定したソフトウェアだけをローカルプロキシポート経由にしたい場合 | アプリ自体がプロキシ設定に対応している必要があります |
クライアントに「ルール」「グローバル」「直接接続」モードがある場合、これは通信がどの出口を選ぶかを示します。ルールモードはドメイン、IP、アプリのルールに基づいてノードを経由するか判断します。グローバルモードはより多くの通信を現在のノードへ送るのが一般的です。直接接続モードではノードを経由しません。日常利用では、まずルールモードを選び、通信の取りこぼしや誤った振り分けに応じて調整するとよいでしょう。
接続後に正常に機能しているか確認する方法
クライアントに「接続済み」と表示されても、ローカルプログラムが何らかの接続処理を完了したことを示すだけで、対象アプリが必ず選択した回線を経由しているとは限りません。出口アドレス、対象サービスへのアクセス、DNS解決、切断後の復旧まで確認しましょう。それぞれ確認できる内容が異なるため、1項目だけでは不十分です。
段階的に接続を確認する
- まずクライアントのログを確認し、ハンドシェイク失敗、証明書エラー、タイムアウト、DNSエラーが継続していないか確認します。
- 出口アドレスの確認ページを開き、接続前後の地域情報が選択した回線と一致するか比較します。
- 実際に利用したい国際サイトやコラボレーションサービスへアクセスし、ログイン、画像、ファイル、リアルタイム接続がすべて機能するか確認します。
- 接続を切ってから再度有効にし、すでに確立された古いセッションに頼らず、クライアントが復旧できるか確認します。
- 別の回線へ切り替えて同じテストを行い、特定ノードの問題か、端末設定の問題かを切り分けます。
ブラウザーのキャッシュにより、オフライン後も古いページが表示される場合があります。また、既存の接続が一時的に維持されることもあります。確認時はページを再読み込みするか、新しいリクエストを送ってください。ブラウザーは使えるのに対象のデスクトップアプリが使えない場合は、そのアプリがシステムプロキシを迂回している可能性をまず疑います。すべてのプログラムが使えない場合は、ノード、サブスクリプション、システム時刻、ローカルファイアウォールを確認します。
ログを確認するときは、完全なサブスクリプションURL、認証情報、ノードの認証情報を公開しないでください。サポートへ問い合わせる場合は、エラーの種類、発生時刻、プロトコル名、回線地域、クライアントのバージョンを残し、機密情報を加工して提出できます。ログの「接続拒否」は通常、接続先が接続を受け付けなかったことを示します。「タイムアウト」は、経路に到達できない、ネットワーク制限、ノードの状態に関係する可能性が高く、「証明書名の不一致」はドメイン名とTLSパラメーターの確認が必要です。
スプリットトンネリングとDNSリークへの対処
スプリットトンネリングの目的は、すべての通信を同じ経路へ送ることではなく、リクエストごとに適切な出口を使い分けることです。ローカルサービス、LAN上のデバイス、地域判定に関係する国内アプリは通常、直接接続にできます。国際回線が必要なドメインやアプリはノードへ渡します。適切な振り分けにより不要な迂回を減らし、グローバルプロキシによってローカル印刷、ファイル共有、社内ネットワークが使えなくなる事態も避けられます。
ルールは、ドメイン、IPアドレス帯、プロセス名、ルールセットなどに基づいて設定できます。ドメインルールは分かりやすい一方、対象サービスが複数のCDNドメインを使うことがあります。IPルールは明確に適用できますが、アドレスが変わると更新が必要です。プロセスルールは特定アプリに向いていますが、補助プロセスが開始する通信を取りこぼす場合があります。実際の設定では、これらを組み合わせることが多いでしょう。
ルールの順序も重要です。多くのクライアントは上から順に照合し、該当すると後続の判定を行いません。範囲の広い直接接続ルールを先頭に置くと、本来回線を経由すべきリクエストまで先に直接接続する可能性があります。反対に、範囲の広いプロキシルールはLANやローカルサービスを迂回させることがあります。ルールを変更したら、古い接続を切って再テストしてください。既存のセッションには新しい方針がすぐ反映されない場合があります。
DNSリークとは
DNSリークとは通常、通信はプロキシ回線を経由しているのに、ドメイン名の問い合わせだけが利用中のネットワークのDNSリゾルバーによって直接処理される状態を指します。出口経路と名前解決の経路が一致しなくなり、対象ドメインから現在の出口地域に適さないアドレスが返される可能性があります。まったくアクセスできなくなるとは限らず、画像だけ遅い、地域向けコンテンツが異なる、一部のサブドメインに失敗するといった形で現れることもあります。
システムプロキシモードでDNSをプロキシへ渡すかどうかは、クライアント、ブラウザー、アプリの実装によって異なります。ローカルで名前解決してから対象IPをプロキシへ渡すアプリもあれば、プロキシプロトコルとクライアントによってリモートで名前解決できる場合もあります。TUNモードはDNSをより統一的に処理しやすいものの、クライアントのDNSリダイレクト、仮想DNS、分流DNSの設定が正しいか確認する必要があります。
ブラウザーに内蔵されたセキュアDNSが、クライアントの想定する名前解決経路を迂回することもあります。出口地域が正しいのにDNSテストでローカルのリゾルバーが表示される場合は、ブラウザー独自のDNSを一時的に無効にし、システムの名前解決結果と比較できます。クライアントでリモート名前解決が有効になっているか確認する方法もあります。複数のDNSツールを重ねて使うと、ブラウザー、システム、クライアント、仮想ネットワークアダプターの間でリクエストが何度も書き換えられるため注意してください。
スプリットトンネリング設定の実践原則
- まずはクライアントが管理する基本ルールを使い、最初から出所不明の大規模なルールセットを追加しないでください。
- LANと端末自身のアドレスは直接接続にして、印刷、ファイル共有、ローカル開発サービスへの影響を避けます。
- 実際に失敗したドメインだけを小さく追加し、後で戻せるよう変更理由を記録します。
- ルールを更新したら接続を再確立し、対象アプリとDNSの経路を再確認します。
- 社内ネットワーク、仮想マシン、コンテナ環境では、重複するネットワーク帯やルート優先度の競合がないか確認します。
自動起動、自動接続、サブスクリプション更新
「クライアントを自動起動する」と「起動後に自動接続する」は別の設定です。前者はプログラムを起動するだけで、後者が回線を選択してプロキシを有効にします。自動起動だけを有効にすると、Windowsへのログイン後にクライアントのアイコンが表示されても、通信は直接接続のままの場合があります。設定後は再ログインし、クライアントが起動するか、サブスクリプションを読み込めるか、回線が接続されるか、システムプロキシが正しく復元されるか確認してください。
自動接続の前に、安定したデフォルト方針を選んでおきます。クライアントがグループ選択に対応している場合は、利用可能な回線から自動選択できます。最後に使ったノードだけを記憶するタイプでは、そのノードが停止すると再試行を繰り返す可能性があります。一時的なテストノードを長期のデフォルトに設定したり、TUNの互換性を確認しないままシステム起動時に有効化したりしないでください。
サブスクリプションの自動更新を使うと回線の変更をクライアントへ反映できますが、重要な会議や大容量ファイルの転送中は更新を避けてください。更新後に設定を再読み込みするクライアントがあるためです。更新後にノードが消えた場合は、まずサブスクリプションのグループとフィルター条件を確認し、次に更新ログを見ます。すぐにすべてのローカル設定を削除する必要はありません。
Windowsのスタートアップアプリ管理では、ログイン時にクライアントを実行できる状態か確認できます。クライアント側で自動起動を有効にしているのに起動しない場合は、システムのスタートアップ項目が無効になっていないか確認してください。管理者として実行すると、起動時の動作に影響することがあります。標準アカウントでログインした際、権限昇格が必要なプログラムは確認なしに起動できない場合があります。クライアントの説明書に従って必要なネットワークサービスを導入し、画面全体を常に高い権限で実行するのは避けるのが適切です。
スリープ復帰後やネットワーク切り替え後は、以前の接続がすでに無効になっていても、クライアント画面には一時的に接続中と表示される場合があります。ネットワーク変化時の再接続に対応するクライアントなら、通常はセッションを再確立します。復旧しない場合は、いったん切断してから再接続してください。有線、無線、仮想ネットワークアダプターを頻繁に切り替える場合は、デフォルトルートとDNSが更新に追随しているか重点的に確認します。
Windowsでよくある接続問題の切り分け順
ネットワーク問題を切り分けるときは、一度に1つの条件だけを変更するのが最も効果的です。まずサブスクリプションを更新できるか確認し、次にノードがハンドシェイクできるかを確認します。その後、対象アプリがプロキシを経由しているかを判断し、最後にDNS、スプリットトンネリング、システムドライバーを確認します。段階を飛ばして多くの設定を一度に変更すると、単純な問題でも再現が難しくなります。
クライアントは接続できるが、ウェブページが開けない
まずシステムプロキシが有効か、ブラウザーが独自のプロキシ設定を使っていないか確認します。次にDNSが応答を返しているか確認してください。回線を切り替えても変わらない場合は、他のプロキシツールやネットワークフィルターを一時的に終了し、ローカルポートやシステムプロキシの二重使用を避けます。TUNモードでは、仮想ネットワークアダプターにルートとDNSが設定されているかも確認します。
ブラウザーは正常だが、デスクトップアプリが接続できない
これは通常、ブラウザーはシステムプロキシに従う一方、デスクトップアプリは従っていないことを示します。まず対象アプリにプロキシ設定があるか確認し、設定がない場合はクライアントとの互換性を確認してからTUNモードを試します。タスクバーのアイコンだけでアプリの通信が回線に入ったと判断しないでください。クライアントの接続ログやプロセス単位の通信記録のほうが参考になります。
サブスクリプション更新後に回線が表示されない
サブスクリプションの更新が成功したか、クライアントでノードフィルターが有効になっていないか、現在のコアがサブスクリプション内のプロトコルに対応しているか確認します。古いコアではHysteria2、TUIC、新しい転送パラメーターを認識できない場合があります。その場合は、サービスの管理画面からクライアントまたはコアを更新し、認識できない項目を手動で削除しないでください。
接続後に国内サイトやLANが使えない
まずグローバルモードからルールモードへ戻し、LANアドレスが直接接続になっているか確認します。TUNを使っている場合は、仮想ネットワークアダプターのルートがローカルネットワーク帯を上書きしていないか確認してください。企業ネットワークと家庭内LANが同じプライベートネットワーク帯を使っている場合があり、仮想マシンやコンテナが加わると競合しやすくなります。実際のルートテーブルに基づいて調整し、すべての通信を強制的にノードへ送らないようにしましょう。
UDPプロトコルで接続を確立できない
Hysteria2とTUICはUDPに依存します。利用中のネットワークがUDPを制限していると、クライアントがタイムアウトしたり、フォールバックに失敗したりする場合があります。まずサービス側が提供する互換回線へ切り替え、基本ネットワークとサブスクリプションが利用できることを確認してから、UDP環境の問題かどうかを判断します。1本のUDP回線が失敗しただけで、サブスクリプション全体が使えないと判断しないでください。
他のプラットフォームでは使えるが、Windowsでは使えない
プラットフォームによって通信の取り込み方法は異なります。macOSとiOSは通常、システムのネットワーク拡張やシステム設定によって権限を取得します。Androidはシステムが提供するVPNサービスインターフェースを使い、Linuxはデーモン、ルート、ファイアウォールルールに依存することが多いでしょう。Windowsではシステムプロキシ、TUNドライバー、ネットワークインターフェースの優先度が関係する場合があります。他のプラットフォームで同じサブスクリプションが使えることは、サーバー側の設定が基本的に有効だと示すだけです。Windowsクライアントのコア、ドライバー、プロキシモードは個別に確認する必要があります。
基本設定が完了したら、動作確認済みの設定を1つ保存し、その後でカスタムルール、TUN、アプリ別の振り分け、自動接続を少しずつ追加するのがおすすめです。後から変更して問題が起きても、動作する状態へすぐ戻せます。Windowsのネットワーク高速化で重要なのは、設定項目を増やすことではなく、サブスクリプション、プロトコル、回線、通信の取り込み方法、DNS経路を一致させることです。