海外ネットワークトラブル対処

切り分け方針:まず障害がどの層にあるかを見極める

切り分けの目的は、すべての設定を一通り変更することではなく、最小限の操作で問題を特定の区間に絞り込むことです。海外へのアクセスは少なくとも4つの区間を通ります。端末からローカルネットワークまで、ローカルネットワークから回線の入口まで、回線の入口から目的のサイトまで、そして目的のサイトから結果が戻ってくるまでです。どの区間で問題が起きても、利用者から見た症状は「開けない」になり得ますが、対処法はまったく異なります。

まず「接続できない」と「接続はできるが遅い」は別物だと切り分けます。前者はリンクの確立に失敗している状態、後者はリンクは使えるが品質が足りない状態で、切り分けの道筋は重なりません。混ぜて設定をいじると、問題はかえって複雑になります。時間軸の違いも見ておきます。初回設定の時点で失敗する場合は設定方法やプラットフォームの互換性が原因のことが多く、しばらく使ったあと急に使えなくなった場合はネットワーク環境、回線の割り当て、アカウントの状態が変わった可能性が高いです。時間軸が違えば、先に調べる方向も変わります。

4層モデル:症状をどの区間に当てはめるか

この表の役割は、30秒以内にどこから手を付けるかを決めることです。症状が「ローカルネットワーク」の行に当てはまるなら、まずクライアントを切断し、ローカルネットワーク自体が使えることを確認してください。ローカルネットワークが不通の状態ではどのプロキシ設定も効かないので、クライアントをいじり続けても時間の無駄になります。

3ステップの切り分け

次の3ステップで順に変数を置き換えていきます。各ステップで変える条件は1つだけにしてください。結果に意味が出るのはその場合だけです。3つ同時に変えると、復旧してもどれが効いたのか分かりません。

1. 回線を変える

   クライアントで別の回線に切り替えます。優先するのは IEPL 専用線です。切り替えて復旧したなら、問題は元の回線に集中しています。回線名、地域、問題が出た時間帯を控え、サポート依頼に添えてください。切り替えても失敗する場合はステップ2へ進みます。

2. 端末を変える

   同じアカウントで、別の端末から同じ回線に接続します。別の端末で正常なら、問題は元の端末のクライアントかシステム設定にあります。該当プラットフォームの章に戻って自己点検してください。2台とも失敗する場合はステップ3へ進みます。

3. ネットワークを変える

   現在の Wi-Fi や固定回線をモバイルネットワークのテザリングに置き換えて、もう一度接続します。テザリングで復旧するなら、問題は元のネットワークの出口、ルーター、回線事業者側にあり、アカウントや回線とは関係ありません。

3ステップすべてが失敗したなら、単一障害点ではないとほぼ判断できます。そのまま第9章のサポート依頼の手順に進み、クライアントで何度も試すのはやめてください。再インストールや切り替えを繰り返すと、正常だった設定まで壊してしまい、後の切り分けが難しくなります。

切り分けの前に記録しておく5項目

記録は形式的な作業ではありません。回線の割り当ては動的なため、同じ問題でも時間帯によって現れ方が変わります。記録があれば規則性を判断できますが、なければ印象で説明するしかなく、やり取りの手間が何倍にもなります。

• 問題が発生した時刻。分単位まで記録し、タイムゾーンも添える。
• そのとき使用していた回線名と地域、および他の回線に切り替えたかどうか。
• クライアントのプラットフォームと OS のバージョン(Windows / macOS / iOS / Android / Linux)。
• エラーメッセージの原文またはスクリーンショット。「開けない」だけでは不十分です。
• すでに試した操作。例:「3本の回線、2台の端末、2つのネットワークで切り替え済み」。

サポートに連絡すべきタイミング

次のような場合は自己点検を続けず、そのままサポートへ依頼してください。

• 同じアカウントで、2本以上の回線、2台以上の端末、2つの異なるネットワークのいずれでも接続できない。
• 1本の回線だけが1日以上続けて失敗し、他の回線は正常。
• アカウント側の異常:ログインできない、サブスクリプションの取得に失敗する、注文や支払いの状態が想定と違う。
• クライアント自体がクラッシュする、繰り返し強制終了する、インストールが完了しない。

逆に、次のような場合はまず自己点検をおすすめします。1台の端末だけ問題が出る、特定の1サイトだけ開けない、特定の時間帯だけ遅くなる、回線を変えれば復旧する。いずれも単発の現象で、自分で確認したほうが返信を待つより速いことがほとんどです。

まったく接続できない:ローカルネットワークからアカウント状態まで順に調べる

「まったく接続できない」とは、クライアントで接続を押しても「接続中」のまま止まる、あるいは接続失敗と表示され、どのサイトも開けない状態を指します。この章では近いところから遠いところへ、端末 → システム → ローカルネットワーク → 回線 → アカウントの順に調べます。順番は飛ばさないでください。飛ばしながら変更すると複数の変数が同時に入り込み、最後には「変更前がどうだったか」すら分からなくなります。

まずクライアントの3つの状態を読み取る

クライアントの「接続済み」はローカルのトンネルが確立したことだけを意味し、出口が使えることは意味しません。本当に有効になったかを確認できるのは出口 IP の変化だけです。ですから最初に見るのはボタンの色ではなく、IP 確認ページを開いて出口 IP の所在地が選択した回線の地域と一致するかどうかです。一致しないなら通信は外に出ておらず、その後の「開けない」という判断はすべて成り立ちません。

5つのプラットフォームのクライアントはいずれも動作ログ(一部のプラットフォームでは「接続ログ」)を提供しています。ログの最終行を見れば、どこで止まっているかがおおむね分かります。ハンドシェイクで止まっているならローカルネットワークがポートを遮断しているかシステム時刻のずれが原因、認証で止まっているならアカウントやサブスクリプションの状態に問題、短い間隔で再接続を繰り返しているならローカルネットワークが不安定かネットワークアダプタが省電力になっている可能性が高いです。

システム時刻のずれは最も見落とされやすい原因

接続処理は TLS ハンドシェイクに依存しており、TLS は端末の時刻と標準時刻の差が数分以内であることを要求します。システム時刻が正確でないと、「接続中」のまま止まるか証明書エラーが出ますが、利用者は回線が壊れたと思い込み、回線を切り替え続けて問題が解決しません。

• Windows:設定 → 時刻と言語 → 日付と時刻 で「時刻を自動的に設定する」をオンにします。
• macOS:システム設定 → 一般 → 日付と時刻 で自動設定をオンにします。
• iOS:設定 → 一般 → 日付と時刻 で「自動設定」をオンにします。
• Android:設定 → システム → 日付と時刻 で自動設定をオンにします(メーカーによってメニューの階層が多少異なります)。

変更したらクライアントを再起動してもう一度試します。長期間ネットにつないでいない端末は時刻のずれが数十分に達することがあるため、その場合は特に時刻の校正を先に行ってから他を確認してください。

ローカルネットワークとセキュリティソフト

• サードパーティのファイアウォールやセキュリティソフトの「ネットワーク保護」「通信監視」がトンネルの確立を遮断することがあります。いったん無効にして試してください。
• システムのプロキシ設定に古いプロキシアドレスが残っていないか確認します(Windows:設定 → ネットワークとインターネット → プロキシ)。
• ルーターのアクセス制御、ペアレンタルコントロール、広告ブロック機能が回線の入口を不審な宛先として遮断することがあります。
• 会社や学校のネットワークでは一般的なポートしか通していないことがあります。その場合はプロトコルかポートを変えると復旧することがほとんどです。

回線とプロトコルの切り替え

まず IEPL 専用線に切り替えてもう一度試します。すべての回線で失敗する場合はプロトコルを変えます。Trojan、VLESS、Hysteria2、Shadowsocks の間で、1回につき1つだけ変えてください。特定のプロトコルが特定のネットワークで遮断されるのはよくあることで、別のプロトコルに変えるとすぐ復旧することが多く、プランの買い直しやサブスクリプションの再インポートは不要です。

アカウント状態の自己点検

• プランが有効期間内か、通信量を使い切っていないか(通信量は開通日ごとに毎月リセットされます)。
• サブスクリプション URL を他人と共有していないか(共有するとログイン状態が互いに押し出されます)。
• 短時間に複数の地域から繰り返しログインし、異常判定に引っかかっていないか。

登録にメールアドレスは不要で、ユーザー名とパスワードだけで完了します。そのためアカウント関連の操作はすべてユーザーパネル内で完結します。パスワードを忘れた場合もパネルの再設定手順に従うだけで、追加の情報は必要ありません。

症状の対応表

接続できるのにページが開かない

この種の問題に共通するのは、クライアントは接続済みと表示されるのに、ブラウザではページが読み込み中のままになる、あるいは「このサイトにアクセスできません」と表示される点です。まず回線はいじらず、次の順序で通信が本当にプロキシを通っているかを確認します。接続できたのに開けないケースのほとんどは、最初の2ステップで止まっています。

「接続済み」は「プロキシ経由」ではない

クライアントには2つの動作方式があります。システムプロキシモードはシステムのプロキシ設定を書き換えるだけで、ブラウザなどその設定に従うアプリはプロキシを通りますが、他のアプリは影響を受けません。TUN(仮想ネットワークアダプタ)モードは、システムプロキシを認識しないアプリを含むすべての通信を引き受けます。クライアントがシステムプロキシモードで、ブラウザにプロキシ設定を乗っ取る拡張機能が入っていると、システム設定が上書きされ、クライアントは接続済みなのにブラウザは開けない、という状態になります。

判断は簡単です。本サービスの IP 確認ページを開き、表示される出口 IP の所在地が選択した回線の地域と一致するかを見ます。一致しなければ通信はプロキシを通っておらず、原因はクライアントのモードかブラウザ拡張にあります。一致していればプロキシは機能しているので、先へ進みます。

コマンドラインで問題を1つの層に絞り込む

ブラウザが出すエラーは大づかみなことが多いのに対し、コマンドラインなら範囲を直接絞り込めます。次の3行はそれぞれ、目的のサイトに到達できるか、ドメインを解決できるか、解決結果が安定しているか、という3つの問いに答えます。

# 1. 目的のサイトに到達できるか(ドメインは例です。実際にアクセスしたいサイトに置き換えてください)
curl -I --max-time 10 https://www.example.com

# 2. DNS 解決のみを行い、ドメインからアドレスを引けるか確認する
nslookup www.example.com

# 3. 指定した DNS でもう一度解決し、2回の結果が一致するか比べる
nslookup www.example.com 1.1.1.1

curl が 200 か 301 を返すならリンク自体は通っており、問題はブラウザ側です。curl がタイムアウトするのに nslookup が結果を返すなら、問題は出口か目的のサイトにあります。nslookup 自体が失敗するなら、第8章の DNS の切り分けに進んでください。3回のテストは同じネットワーク環境で行ってください。そうでないと結果を比べられません。

状況別の判断

• すべてのサイトが開けない:まず DNS とトンネルが有効かを確認し、次に回線、最後にアカウントの状態を見ます。
• 一部のサイトだけ開けない:分流ルールでそれらのドメインが直結に指定されていないか、目的のサイト自体がメンテナンス中でないかを確認します。
• ブラウザだけ開けず、他のアプリは正常:ブラウザの拡張機能と、ブラウザ内蔵の暗号化 DNS 設定を確認します。
• 1台の端末だけ開けない:別の端末と比べ、アカウントの問題ではなく端末側の問題だと確認します。

IPv6 が引き起こす「半分だけ使える」状態

一部の回線では IPv4 と IPv6 のアドレスが同時に配布され、システムは IPv6 を優先します。回線が IPv4 しか扱わない場合、「開けるサイトと、ずっと読み込み中のサイトがある」という一見ランダムな現象が起きます。対処は2つです。クライアントで TUN モードを有効にしてすべての通信をトンネルに入れるか、システムのネットワーク設定で IPv6 を一時的に無効にしてからもう一度試して結果を比べます。

目的のサイト側の問題

目的のサイト自体の障害も見落とさないでください。別の回線、別の端末、別のネットワークでそれぞれ同じサイトにアクセスし、3つとも失敗するのに他のサイトはすべて正常なら、問題は目的のサイト側にあり、本サービスとは関係ないとほぼ判断できます。相手側の復旧を待つだけで済みます。

ブラウザ拡張とセキュリティソフト

広告ブロック、スクリプト管理、プロキシ切り替え系の拡張は、いずれもリクエストの経路を変えます。切り分けの際はまずすべて無効にし、正常に戻ることを確認してから1つずつ有効にして、どの拡張が影響しているかを特定します。この作業は数分で済みますが、複雑に見える問題のかなりの部分を排除できます。

サブスクリプション更新失敗:リンク・キャッシュ・状態の確認

サブスクリプションはクライアントが回線リストを取得する経路です。更新に失敗しても、クライアントは前回取得に成功したノードを保持していることが多く、症状は「接続はできるがノードリストが古い」こともあれば、サブスクリプション更新失敗と直接表示されることもあります。まずどちらかを確認し、それから対処を決めます。前者は多くの場合そのまま使えて、後者はすぐに対処が必要です。

まず3つを確認する

• 端末が現在正常にネット接続できていること。サブスクリプションの更新自体に正常な通信が必要で、オフラインで更新を押せばエラーになるのは当然です。
• システム時刻が自動設定になっていること。時刻のずれは TLS の段階でリクエストを失敗させますが、エラー表示はネットワーク関連に見えがちです。
• プランが有効期間内で、通信量を使い切っていないこと(通信量は開通日ごとに毎月リセットされます)。

3つとも問題がなければ先へ進みます。この3項目はサブスクリプション更新失敗の最もよくある原因を覆っているので、先に除外すれば大幅に時間を節約できます。

サブスクリプション URL の形式

サブスクリプション URL は資格情報を含むリンクで、クライアントはこれを通じて回線リストを取得します。以下は形式の例です。実際の URL はユーザーパネルにログインし、「概要」ページでコピーしてください。

# サブスクリプション URL の例:形式の説明用で、実際に使える URL ではありません
https://example.com/sub?token=YOUR_TOKEN

# 一部のクライアントは種類ごとに異なる形式を返せます(例)
https://example.com/sub?token=YOUR_TOKEN&flag=clash

サブスクリプション URL はアカウントに紐づき、アクセス資格情報を含むため、パスワードと同じです。グループに送ったり、スクリーンショットを外部に出したり、公開の設定ファイルやコードリポジトリに貼ったりしないでください。複数の端末で使う場合は、各端末で同じ URL をそれぞれインポートすればよく、追加の申請は不要で、台数の制限もありません。

2つのインポート方法

リンクでのインポートが第一選択です。ノードの手動追加は予備手段で、クライアントにサーバーアドレス、ポート、プロトコル、資格情報を1つずつ入力します。手動で追加したノードはその後の更新で変化しないため、手動の回線がつながらないと気づいたら、まずリンクでのインポートに戻して、回線自体が調整されたのかを確認してください。

更新が失敗するよくある原因

更新の頻度とタイミング

週に1回の更新をおすすめします。回線や地域を変えたとき、速度が落ちたと感じたときは、まず手動で更新してから様子を見てください。プロトコルをすぐ変える必要はありません。更新後はノードリストが地域ごとに再グループ化されます。ある地域のノード数が変わっていたら、サーバー側で回線を調整していることが多いので、しばらくしてからもう一度更新すれば問題ありません。

速度低下と夜間の混雑による遅延

「遅い」は結果であって原因ではありません。まずボトルネックがどの区間にあるかを測り、それから何を変えるかを決めます。この章は「まずローカルを測り、次に出口を測り、最後に回線を調整する」順で進みます。逆の順でやると、ローカル回線の帯域の問題を回線の問題と誤認しやすく、回線を一通り試しても改善しません。

まずローカル回線の帯域を測る

クライアントを切断し、ローカル回線の実測速度を測って結果を控えます。次にクライアントを接続してもう一度測ります。2回の差が、プロキシ経路による損失です。ローカル回線自体の数値が低い場合、どの回線に変えても速くはならないので、まず回線事業者に連絡すべきです。

測速の際は2点に注意します。2回とも同じ測定サービスを使うこと(そうでないと結果を比べられません)。バックグラウンドのダウンロード、クラウドストレージの同期、OS の更新を止めること(帯域を占有し、結果が大きく歪みます)。測定結果はサーバー側の負荷にも左右されるため、1回の結果では判断できません。3回続けて測り、中央値を取るとより信頼できます。

回線タイプの違い

3タイプの回線はいずれも 110+ カ国 / 250+ 回線の範囲に含まれ、クライアントで地域とタイプから直接絞り込めます。夜間の混雑時に IEPL 専用線を優先するのは、専用線のチャネルが公共インターネットの国際出口を通らず、全体の混雑の影響を受けにくいためです。直結回線は経路が最短ですが、混雑する時間帯に公共の出口の渋滞に最も影響されやすいのも事実です。

プロトコルとオーバーヘッド

プロトコルはカプセル化の方式と追加のオーバーヘッドを決めます。Hysteria2 は QUIC ベースで、パケットロスが多いネットワークでより安定し、回線品質が変動しやすい場面に向きます。Trojan と VLESS は TLS を使い、互換性が高いので日常利用の大半に向きます。Shadowsocks はオーバーヘッドが小さく、古い端末でよく機能します。プロトコルはいつでも切り替えられ、切り替え後は一度再接続が必要ですが、サブスクリプションの再インポートは不要です。

端末側のボトルネック

• Wi-Fi の帯域:2.4GHz は範囲が広い代わりに速度の上限が低いので、近距離では 5GHz を優先して接続します。
• 古い端末の暗号処理性能:古いプロセッサは暗号化と復号の負荷が大きく、ページは開けるのに動画が止まる、という形で現れます。
• バックグラウンドのタスク:OS の更新、クラウドストレージの同期、ゲームプラットフォームのダウンロードは帯域を占有し続けます。
• ルーターの性能:エントリーモデルのルーターは、多端末を同時に使うと回線より先に転送能力が限界に達することがあります。

夜間の混雑時の対処順序

次の順に試し、1回につき1項目だけ変え、変えたらすぐ再測定します。

1. IEPL 専用線に切り替える

   目的のサイトに近い地域を優先します。同じ地域に専用線が複数ある場合は1本ずつ試し、混雑時間帯にどれが安定しているかを記録します。

2. プロトコルを切り替える

   Trojan、VLESS、Hysteria2、Shadowsocks の間で別のものに変えます。特にパケットロスが目立つときは、QUIC ベースのプロトコルのほうが改善が大きい傾向があります。

3. 分流を確認する

   国内サイトは直結にして、トンネル内の無駄な通信を減らします。同時に、目的のサイトを誤って直結に通すルールがないか確認します。

4. ローカル側の問題でないことを確認する

   別の端末、別のネットワークでもう一度測ります。元の端末だけ遅いなら、問題は端末かローカルネットワークにあり、回線とは関係ありません。

時間帯と対処の目安

特定の時間帯だけ遅くなり、回線を変えると明らかに改善するなら、アカウントや端末の問題ではなく国際出口の混雑だとほぼ判断できます。スポーツのライブ配信のように遅延に敏感な場面の回線選びは、スポーツ中継向け VPN の選び方 の記事を参考にしてください。

頻繁な切断とモバイル端末のバックグラウンド切断

切断には2種類あります。実際に切断され、クライアントの状態が未接続に戻るものと、「見かけの切断」で、クライアントは接続済みのままなのに通信が止まるものです。切り分けの方向はまったく異なるので、まずどちらかを見分けてから手を動かしてください。そうしないと、見当違いの方向で延々と試すことになります。

まず本当の切断と見かけの切断を分ける

• 本当の切断:クライアントの状態が未接続に戻り、ログに切断の記録が残る。調べる方向はローカルネットワーク、ネットワークアダプタの省電力、リンク品質です。
• 見かけの切断:状態は接続済みのままだが、ページが開けない。調べる方向はキープアライブ、DNS、クライアントプロセスが OS に回収されることです。

見分け方:切断が起きた瞬間に IP 確認ページを開きます。開ければトンネルは生きており、アプリケーション層の問題です。開けなければトンネルは本当に切れています。この作業は数秒で済みますが、その後の調査方向を決められます。

デスクトップ:ネットワークアダプタの省電力と電源プラン

• Windows:デバイスマネージャー → ネットワークアダプター → プロパティ → 電源の管理 で「電力節約のために、コンピューターでこのデバイスをオフにできるようにする」のチェックを外します。
• Windows:コントロールパネル → 電源オプション でプランを「高パフォーマンス」にし、プロセッサとアダプタが頻繁にクロックを下げるのを避けます。
• macOS:システム設定 → バッテリー で「低電力モード」をオフにするか、使用中は電源に接続します。

この3項目はデスクトップでの切断の最もよくある原因です。無線アダプタがアイドル時に省電力状態に入ると復帰に時間がかかり、一定間隔で引っかかる、あるいはそのまま切断されるという形で現れます。

モバイル:バックグラウンドで OS に回収される

iOS も Android も、メモリが逼迫したときや省電力モードでバックグラウンドのプロセスを回収します。プロキシのプロセスが回収されると、他のアプリに切り替えてしばらく戻ってきたときには接続が切れており、しかも何の通知も出ません。

• iOS:設定 → 一般 → App のバックグラウンド更新 でクライアントの更新を許可し、あわせて低電力モードをオフにします。
• Android:設定 → アプリ → クライアント → バッテリー で「制限なし」を選ぶか、省電力の除外リストに追加します。
• Android:最近使ったタスクの一覧でクライアントをロックし、一括クリアの対象にならないようにします。
• OS 標準の「スマート省電力」「ディープスリープ」系の機能によるクライアントの制限を解除します。

ネットワーク切り替え時の再接続

Wi-Fi からモバイルネットワークへ切り替えたとき、あるいは Wi-Fi 間をローミングしたときは、トンネルを確立し直す必要があります。十数秒待って復旧するのは正常な動作です。いつまでも復旧しない場合は、手動で切断してから再接続すれば済み、端末の再起動は不要です。2つのネットワークを頻繁に行き来する場合は、接続が安定してから長時間のタスクを始めてください。

ルーターと光回線終端装置

長時間電源を入れたままのルーターは、セッションテーブルの枯渇やメモリ使用率の上昇を起こすことがあり、プロキシ接続の切断だけでなくネットワーク全体が断続的に重くなる形で現れます。光回線終端装置とルーターの電源を一度切って入れ直し、そのあと1日観察してください。切断の頻度が明らかに下がれば、問題はローカルネットワーク機器側にあります。

バンドステアリングとローミング

一部のルーターは 2.4GHz と 5GHz を同じ SSID にまとめており、端末が帯域を行き来するたびに接続が短時間切れます。家中に複数のルーターがある場合、ローミング設定が適切でないと同じ現象が起きます。まず2つの帯域を別々の名前に分け、片方に固定して接続し、切断が減るか観察してください。

再インストールを繰り返すより記録のほうが役に立つ

切断の間隔、持続時間、そのとき使っていた回線とネットワークの種類を記録します。一定間隔の切断はキープアライブや省電力設定が原因のことが多く、不規則な切断はリンク品質やローカルネットワークの問題である可能性が高いです。Android 端末は省電力の仕様差が大きいため、インストールから除外リストへの追加までの流れは Android で VPN をゼロから設定 を参照してください。

特定のアプリがプロキシを通らない

ブラウザは正常なのに、特定のデスクトップソフト、ゲーム、コマンドラインツールがつながらない場合、多くは回線の問題ではなく、そのアプリがプロキシを通っていないことが原因です。原因は3点に集約されます。プロキシモード、分流ルール、アプリ自身の通信の扱いです。この3点を順に確認すれば、ほぼ特定できます。

プロキシモードが何を引き受けるかを決める

分流ルールの照合順序

分流ルールはドメイン、IP、アプリ名の順に照合され、先に一致したものが有効になります。目的のドメインが直結ルールに書かれている場合や、より前にあるルールに先に一致した場合、そのアプリはクライアントのアプリ一覧に入っていてもプロキシを通りません。

調べ方:クライアントの接続ログを開き、問題のアプリを一度操作して、ログに対応する接続記録が出るかを見ます。記録がなければ通信がそもそもクライアントに入っていません。記録はあるが直結と表示されていればルールが通しています。記録がありプロキシを通っていれば、問題はアプリ自身か目的のサイトにあります。

よくある設定ミス

• ルール一覧に手動で「直結」の項目を追加し、後で削除し忘れている。
• 一部のプロセスだけをプロキシの対象にしており、そのアプリが一覧に入っていない。
• アプリが独自のネットワークスタックを使い、一部のダウンロードツールやゲームプラットフォームがシステムプロキシを迂回する。
• アプリが IPv6 を優先するのに、回線が IPv4 しか扱わない。

ゲームと UDP を使うアプリ

ゲーム系のアプリは UDP を多用しますが、システムプロキシは通常 TCP しか扱いません。そのため「ブラウザは正常なのにゲームに入れない」は典型的な現象です。こうしたアプリではクライアントで TUN モードを有効にし、UDP 転送に対応していることを確認します。有効にした結果かえって遅延が増える場合は、遅延のより低い地域のノードに戻してください。

AI ツール系のアプリ

ChatGPT、Claude、Gemini などの AI ツールはリンクの安定性に敏感です。多くが長い接続を使うため、途中で切れるとセッションを張り直す必要があり、「ログイン後にずっと読み込み中」あるいは「回答の途中で止まる」という形で現れます。こうした場合は IEPL 専用線に切り替え、そのうえでアプリがプロキシの対象に入っているかを確認してください。より細かい方法は ChatGPT の高速化 ページにまとめています。

有効になったかを確認する

最も直接的な確認方法は、問題のアプリでプロキシ経由でしか開けないアドレスにアクセスするか、アプリ内蔵のネットワーク診断で出口アドレスを見ることです。本サービスの IP 確認ページで現在の出口を確認する方法もあります。デスクトップでのグローバルプロキシと分流の使い分け、および自動起動の設定方法は Windows VPN の選び方 の記事にまとめています。

DNS 異常と出口 IP の自己点検

DNS はドメイン名を IP アドレスに変換する役割を担います。DNS に問題が起きると、症状は紛らわしいものになります。ページは開けないのに通信系アプリは正常だったり、同じ端末で解決できるドメインとできないドメインが混在したりします。まずどれに当たるかを見分け、それから何を変えるかを決めます。

まず3種類に分ける

3種類の対処は異なります。解決失敗はローカルの DNS サービスが使えないことが多く、解決の異常は解決経路に妨害がある場合が一般的です。DNS リークは設定の問題で、解決リクエストをトンネル内に戻す必要があります。

IP 確認ページで3項目を自己点検する

• 出口 IP の所在地が、選択した回線の地域と一致しているか。
• DNS リークの警告が出ていないか。
• クライアントの切断前と切断後にそれぞれ確認し、2回の結果が異なるか比べる。

確認の入口は マイ IP ページにあり、追加のツールのインストールもコマンドラインの知識も不要です。3項目の結果を控えて、サポート依頼に添えてください。

クライアント内の DNS 設定

回線が提供する DNS 解決を優先し、解決リクエストをトンネルと一緒に国外へ出します。DNS を手動で公開アドレスに変更すると、解決リクエストがトンネルを迂回してローカルの回線事業者に戻ることがあり、解決結果に影響するだけでなく、解決の記録がトンネルの外に露出します。明確な理由がない限り、クライアントが配信する DNS 設定を手動で変更しないでください。

ブラウザ内蔵の暗号化 DNS

一部のブラウザには暗号化 DNS(DoH)が内蔵されており、有効にするとシステムとクライアントの DNS 設定を迂回します。ブラウザだけで解決の異常が出る場合は、まずこの項目をオフにするか「システム設定に従う」に変更して、もう一度試してください。この項目は見落とされがちですが、「他のアプリは正常なのにブラウザだけ開けない」という現象を説明できます。

コマンドラインでの切り分け

# システム既定の DNS で解決する
nslookup www.example.com

# 指定した DNS で解決し、2回の結果が一致するか比べる
nslookup www.example.com 1.1.1.1

# Windows:ローカルの DNS キャッシュを消去する
ipconfig /flushdns

# macOS:ローカルの DNS キャッシュを消去する
sudo dscacheutil -flushcache

2回の解決結果が一致しない場合は、解決経路に妨害があることを示します。まずキャッシュを消し、クライアントの DNS 設定を既定値に戻してから、もう一度接続してください。キャッシュ消去後の最初の解決は少し遅くなることがありますが、正常な動作です。

DNS は正常なのにページが開けない

解決が正常で出口 IP も正しいのにページが開けないなら、問題は DNS ではありません。第3章に戻り「状況別の判断」に沿って調べ直し、分流ルールとブラウザ拡張の2点を重点的に確認してください。

台数、アカウント共有、サポート依頼

この章ではアカウント側の問題と、前の8章をすべて調べ終えたあとにどうするかを扱います。アカウント系の問題の特徴は、ローカルでどう設定を変えても改善せず、アカウント側から確認しないと特定できないことです。

台数無制限とは何を意味するか

VPNPF のプランは台数無制限です。同じアカウントで Windows、macOS、iOS、Android、Linux に同時に接続でき、端末ごとに購入する必要も、台数を数えながら使う必要もありません。新しい端末に変えたときは、その端末でサブスクリプションをインポートするだけです。

多くのサービスは台数で課金し、超えると「端末数の上限超過」と表示してプランのアップグレードを求めます。本サービスのプランにはこの制限がないため、自分の端末の間で切り替えるときに台数を気にする必要はありません。ログイン後に弾かれてしまう場合は、台数の制限ではなくアカウント共有によるものがほとんどです。

アカウント共有で何が起きるか

サブスクリプション URL はアカウントに紐づき、アカウントの資格情報と同じです。URL を共有することは、アカウントを他人に使わせることと同じです。複数人で同じアカウントを使うと3つの影響が出ます。同時接続数が大量に占有され、自分が使うときにかえって遅くなる。ログイン状態が互いに押し出され、頻繁に再ログインを求められる。異常なログイン記録が出ても出所が判断できない。

家族や同僚に使ってもらう場合は、同じサブスクリプション URL を共有するのではなく、個別にアカウントを登録することをおすすめします。登録にメールアドレスは不要で、ユーザー名とパスワードだけで完了するため、家族用に1つ用意するコストはごくわずかです。

次の場合は必ずサポートへ依頼してください

• アカウントにログインできず、再設定の手順もうまくいかない。
• サブスクリプションの取得に失敗し、端末やネットワークを変えても失敗する。
• 注文や支払いの状態が実際と一致しない。
• 返金を申請したい(60 日間の無条件返金)。
• 本ガイドの前の8章まで調べても問題が残っている。

サポート依頼に添える情報

情報が揃っていれば通常は1回で特定できますが、揃っていないとやり取りの往復で半日余分にかかります。次の一覧に沿って整理し、そのままサポート依頼に貼り付けてください。

1. アカウント情報

   登録時に使用したユーザー名。パスワードは提供しないでください。サポート依頼にパスワードは不要で、こちらからお尋ねすることもありません。

2. 問題が発生した時刻

   分単位まで記録し、タイムゾーンも添えます。時刻があると、回線の調整かローカルネットワークの変動かを判断しやすくなります。

3. 回線名と地域

   問題発生時に使用していた回線名と地域、および他の回線に切り替えたかどうか、切り替えた結果どうだったか。

4. クライアントと OS

   使用しているプラットフォーム(Windows / macOS / iOS / Android / Linux)と OS のバージョン、およびクライアントのバージョン情報。

5. エラーメッセージの原文またはスクリーンショット

   クライアントのエラー文言をそのままコピーするか、エラー情報全体が写ったスクリーンショットを添えてください。「開けない」という説明だけでは不十分です。

6. すでに行った切り分け

   例:「3本の回線、2台の端末、2つのネットワークで切り替え済みで、症状は同じ」。この項目があると、確認の往復を1回分省けます。

依頼したあと

サポートの入口はユーザーパネル内にあり、ログインすれば依頼の送信と進捗の確認ができます。送信の前に、本ガイドで該当する症状の章を検索することをおすすめします。多くの問題は自己点検の段階で解決できます。支払い方法は Alipay、WeChat Pay、USDT に対応しています。注文関連の問題は、支払い時刻と金額をサポート依頼に添えれば十分で、支払い控えのスクリーンショット以外の機微な情報を提供する必要はありません。