海外接続のトラブル解決マニュアル

切り分けの順序:3つの判断を設定変更より先に

接続トラブルは千差万別に見えますが、実際には3つの層に分かれます。アカウントと購読、クライアントと端末、回線とネットワークです。どの層に問題があっても、現れ方は同じことがあります。読み込みが回り続ける、タイムアウトする、ページが開かない。だからこのマニュアルは、まず層を特定し、それから設定を変える順序で進めます。一度に変えるのは1つだけ、変えたらすぐ再テストします。3か所を同時に変えると、復旧してもどれが効いたのか分からず、次に同じ症状が出たときにまた最初からやり直すことになります。

判断その1、アカウントと購読が有効か。ユーザーパネルにログインし、プランが有効期限内で、当月の通信量が残っているかを確認します。通信量は申込日を基準に毎月リセットされ、使い切っても自動で追加されません。使い切ると、すべての回線がつながらない、あるいはつながっても通信が通らない状態になります。この段階ではパネルだけを見て、クライアントには触りません。

判断その2、障害は全体か単発か。別の端末に変える、別のネットワークに変える(たとえば別の端末でテザリングする)、目的のサイトを変える。3回のうち1回でも正常なら、アカウントと回線プール自体に問題はなく、原因はローカル側にあります。3つすべて失敗して初めて、回線を疑う価値が出ます。

判断その3、問題はクライアント側か回線側か。同じ回線で繰り返し失敗し、別の回線なら正常なら回線の問題です。どの回線に変えても同じように失敗するなら、クライアントかローカルネットワークの問題です。この判断で、次に第2章を見るか第3章を見るかが決まります。

この3つを済ませれば、たいていはどの章に飛ぶべきか決まります。次の表はよくある症状と章の対応表です。まず症状から探し、そのうえで章に戻って1つずつ確認してください。

切り分けを始める前に、3つだけ用意しておきます。問題が出ている端末、問題が出た時刻、クライアントのログのうち該当時刻の数行です。問い合わせで最も価値があるのは「つながらない」の一言ではなく、「いつ、どの回線で、どんなエラーが出たか」です。ログの取り方は第10章でまとめて説明します。

再テストの方法も固定します。同じ目的サイト、同じ時間帯、同じコマンドです。設定を変えたらすぐ、異なる3地域のサイトを開いてみるほうが、接続ボタンを何度も押すより状況が分かります。変更後1回目でつながっても、すぐに終わりにせず、10分おいてもう一度テストしてください。断続的な不具合は、最初の成功で隠れやすいからです。

まったくつながらない:購読からローカルポートまで順に排除

まず「つながらない」を3つの現れ方に分けます。接続を押すと回り続ける、数秒で即座に失敗する、接続済みと表示されるのに通信量がゼロのまま。1つ目はハンドシェイクで止まっていることが多く、2つ目はローカル設定かポート、3つ目はトンネルは張れたが通信が通っていない状態です。現れ方が違えば確認の出発点も違うので、まとめて見ると余計に混乱します。

次の6ステップは、アカウントからローカルへ向かう順に並んでいます。どのステップでも単独で結論を出せます。つながったところで止めればよく、それ以上続ける必要はありません。

1. 購読が有効期限内で、当月の通信量が残っているか確認する

   ユーザーパネルにログインし、プランの期限と当月の残り通信量を見ます。月額プランの通信量は申込日を基準に毎月リセットされ、使い切っても自動では追加されません。データパックは使い切るまで有効で期限はなく、月額プランの通信量とは別に計算されます。このステップではパネルだけを見て、クライアントは変更しません。

2. 別の回線で試す

   同じ地域で都市を変える(東京からソウルなど)、あるいは回線タイプを変える(IEPL から中継など)。異なる地域の回線で3本続けて失敗するなら、単一の回線の問題はほぼ除外できます。1本だけ失敗するなら、その回線の問題なので差し替えれば済みます。

3. 別のネットワークで試す

   別の端末でテザリングして PC をつなぐ、あるいはモバイル回線に切り替えます。社内ネットワーク、学校のネットワーク、ホテルのネットワークはポートやプロトコルを制限していることがよくあります。ネットワークを変えて通るなら、原因はローカルネットワークのポリシーであり、アカウントの問題ではありません。この1点で、クライアント設定に費やす時間を大きく減らせます。

4. システム時刻を合わせる

   システム時刻を自動同期に設定します。数分以上ずれていると TLS ハンドシェイクが失敗しますが、クライアントはたいてい「接続に失敗しました」としか表示せず、本当の原因は見えません。合わせたうえでクライアントを再起動して、もう一度試します。

5. 他のプロキシ系ソフトを終了する

   2つのクライアントが同時に動くと、同じローカルポートを取り合います。後から起動したほうは、たいてい何も表示しないまま失敗します。タスクトレイとタスクマネージャーを確認し、使っていないプロキシ、高速化ツール、パケットキャプチャツールをすべて終了して、1つだけ残します。

6. ファイアウォールとセキュリティソフトを確認する

   初回起動時にブロックされた受信規則は、自動では元に戻りません。システムのファイアウォールで該当クライアントを探し、受信と送信の両方が許可されているか確認します。サードパーティのセキュリティソフトの「ネットワーク保護」がトンネルを遮断していることもあるので、一時的に無効にしてから試します。

見落としやすい原因

ローカルポートの競合。クライアントの既定のローカルポートが、すでに別のプログラムに使われていることがあります。画面は正常で接続ボタンも押せるのに、システムプロキシが指すポートには何もいない、という形で現れます。ポートを変えるか、占有しているプログラムを終了すれば解決します。

ネットワーク側の UDP 制限。UDP を速度制限したり、そのまま破棄したりするネットワークがあります。クライアントで TCP に切り替えるか、別の転送方式にして試し、つながればこれが原因です。

ループバックのプロキシ。分割ルールが購読ドメインやパネルのドメインまでプロキシ行きと判定し、そのプロキシがまだつながっていない場合、購読の更新と接続の確立が互いに待ち合い、どうやってもつながらないように見えます。この2つのドメインを直接接続に指定してから、再接続してください。

ルーター側での遮断。ペアレンタルコントロール、利用時間の管理、DNS フィルタはルーター層で遮断します。モバイル回線と比べれば一度で確認できます。

問い合わせに切り替える目安

異なる地域・異なる回線タイプの3本がすべて失敗し、2つの異なるネットワークでも同じように失敗し、システム時刻は合わせ済みで他のプロキシ系ソフトも終了済み。この3つが同時に当てはまるなら、ローカル側の問題ではないとほぼ判断できます。このタイミングで、クライアントのログと問題発生時刻を添えて問い合わせるほうが、試し続けるより効率的です。添付すべき情報は第10章にまとめています。

接続できるのにページが開かない:まず全部か一部かを切り分ける

クライアントは接続済みで通信量も動いているのに、ブラウザでページが開かない。最初にやるのは設定変更ではなく、切り分けです。すべてのサイトが開けないのか、一部だけ開けないのか。この違いで、その後の道筋の9割が決まります。

すべて開けない

すべて開けない場合は、DNS がトンネルに沿っていないか、パケットが経路上で捨てられています。次の3つを順に確認します。

DNS がトンネル内で解決されているか。クライアントで「DNS をトンネル内で解決する」といった項目が有効になっているか、システム DNS が特定のローカルアドレスに固定されていないかを確認します。判定方法は第9章にあります。

MTU が合っているか。トンネルのカプセル化はパケット長の一部を使います。ローカル側が 1500 のままだと大きなパケットが捨てられ、トップページは開くのに画像や動画が読み込めない、ページが途中で止まる、といった形で現れます。フラグメントを禁止した ping で一度測ります。

# Windows
ping -f -l 1472 example.com

# Linux / macOS
ping -M do -s 1472 example.com

1472 に28バイトのヘッダーを足すとちょうど 1500 になります。通れば MTU に問題はありません。「パケットの分割が必要」と出るか、そのままタイムアウトする場合は、数値を 1400 付近まで段階的に下げて試し、クライアントの MTU を 1400〜1450 の間に設定します。トンネル系の問題ではよく使う値なので、ぴったりの数字を探し続ける必要はありません。

分割ルールがブラウザを直接接続と判定していないか。グローバルモードに切り替えて一度動かし、開けるならルールの問題です。ルールモードに戻して、ホワイトリストを1つずつ足していきます。

一部だけ開けない

特定のサイトだけ開けない場合、問題はたいていサイト側にあり、トンネル側ではありません。

地域制限。サイトは出口の地域に応じてサービスを出し分けます。該当する地域の回線を使えば解決します。よく使う地域と用途の対応は第4章にあります。

出口 IP による追加確認。同じ出口を多くの人が使っていると、サイトが追加の確認を求めたり、そのまま拒否したりします。同じ地域の別の回線に変えれば、たいてい通ります。

ローカルキャッシュ。ブラウザやアプリが古い解決結果や古い接続をキャッシュしています。DNS キャッシュを一度消して(コマンドは第9章)、再読み込みします。

動画配信とアカウントの地域。動画配信は出口の地域だけでなく、アカウントの登録地域も見ます。出口を変えてもアカウントの地域が変わっていなければ、一部のコンテンツしか見られません。この場合は回線を変えても解決せず、アカウント側を揃える必要があります。

分割トンネルモードの選び方

切り分けでは、まずグローバルモードで一度動かします。グローバルで通り、ルールで通らないなら、9割は分割ルールの問題です。どちらも通らないなら、DNS と MTU の2項目に戻ります。原因が特定できたらルールモードに戻し、漏れていたドメインをホワイトリストに足します。グローバルのまま常用しないでください。グローバルモードは社内アクセス、LAN 内の機器、ローカルの開発サービスまでまとめてトンネルに入れてしまい、代償が小さくありません。

遅い・夜間の重さ:3種類の「遅い」を先に分ける

遅いといっても少なくとも3種類あります。ずっと遅い、特定の時間帯だけ遅い、特定のサイトだけ遅い。原因も対処もまったく違うので、まとめて変えると労力が無駄になります。まず2分かけてどれかを確認してから手を動かしてください。

ずっと遅い

接続した時点からどの時間帯でも遅い場合は、ローカル側が原因です。順に確認します。自宅回線そのものの実効速度。Wi-Fi が 2.4GHz 帯で動いていないか(近距離なら 5GHz を優先)。ルーターが古くないか、速度制限がかかっていないか。バックグラウンドで OS の更新、クラウドストレージの同期、オンラインバックアップが動いていないか。

もう1つよくあるのが、出口地域を遠く選びすぎているケースです。物理的な距離が下限を決めるので、アジアから欧州の出口に接続すると、回線がどれだけ良くても余分に経路をたどります。近い地域を選ぶのが、体感を最も直接的に改善する一歩です。

特定の時間帯だけ遅い

昼は正常で夜になると遅くなるのは、国際帯域に共通する現象で、特定のサービスの問題ではありません。夜の対処は再接続を繰り返すことではなく、回線タイプを変えることです。

回線タイプはクライアントの回線一覧で確認できます。各回線の後ろにタイプが表示されています。夜の時間帯は、よく使う回線を同じ地域の IEPL 専用線に変えるほうが、地域を変えるより効くことが多いです。

特定のサイトだけ遅い

特定のサイトだけ遅い場合は、まずサイト自体を疑います。共有出口に対して速度制限をしていないか、単一接続に制限をかけていないか、CDN が遠いノードに割り当てていないか。確認は簡単で、同じ回線で同種の別サイトを開いて速度が正常なら、トンネルの問題ではありません。

ブラウザの拡張機能も足を引っ張ります。広告ブロック、スクリプト管理、翻訳プラグインは、海外アクセス時に待ち時間を増幅させます。シークレットウィンドウ(既定で拡張機能を読み込まない)で一度比べれば確認できます。

意味のある測り方

速度測定ソフトのピーク値ではなく、実際の作業の完了時間を見ます。同じ動画を開いてから再生できるまで何秒か、同じファイルをダウンロードし終えるまで何秒か。測るときは3つを固定します。同じ対象、同じ時間帯、同じ操作。回線 A と回線 B をそれぞれ3回測って中央値を取れば、2つの結論に比較可能性が出ます。

本サイトの回線一覧には遅延の数値を載せておらず、リアルタイムの速度測定も表示していません。遅延はローカルネットワーク、時間帯、対象サイトによって変わるため、固定値を書いても参考になりません。実際の体感は、自分のネットワークでしか測れません。

用途別の出口地域の選び方

より詳しい回線選びのルールは回線選択の入門ガイドをご覧ください。全地域と回線の分布はサーバーページに掲載しています。

プラン変更を検討するタイミング

遅いことと「通信量を使い切った」ことは別の問題です。使い切ると、遅くなるのではなく基本的につながらなくなります。通信量が足りないと確認できた場合、月額プランは3つから選べます。¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GB。通信量は申込日を基準に毎月リセットされ、途中でアップグレードした場合は残り日数で差額を精算します。使用量の変動が大きい用途では、データパックを重ねることもできます。¥158/300GB、¥358/1000GB、¥658/3000GB で、使い切るまで有効、期限はありません。詳しい比較は料金プランページをご覧ください。

頻繁な切断:切断の時間パターンから原因を逆算する

切断は回線が不安定だと決めつけられがちです。まず回線を変えるのではなく、パターンを見ます。一定間隔で切れる、ランダムに切れる、ネットワークを変えたときに切れる。3つのパターンはそれぞれ別の原因に対応しており、パターンを見誤らなければ原因はほぼ絞れます。

一定間隔で切れる

5分おき、30分おきなど、ほぼ同じ時刻に切れる場合。この種の切断は回線が落ちているのではなく、セッションが回収されていることが多いです。

キープアライブとタイムアウト。一定時間データのやり取りがないと、クライアントが自ら切断して再接続します。放置すると切れ、通信が発生すると正常というのはこの原因です。クライアントで「接続を維持する」「定期的なキープアライブ」といった項目を有効にします。

セッションのタイムアウト。ルーターや回線事業者側が、長時間アイドル状態のセッションを回収します。現れ方はキープアライブの問題と同じで、対処はルーターのセッションタイムアウトを長くするか、クライアントから定期的にプローブを送るようにします。

ランダムに切れる

決まった時刻ではなく、切れた後に自動で戻ることもあれば手動の再接続が必要なこともあります。よくある原因は3つです。Wi-Fi ローミング(端末が複数のアクセスポイント間を移動するときにトンネルが張り直される)、電波が弱い、省電力設定(第8章)。

対処の順序はこうです。1つの Wi-Fi 帯域と1つのアクセスポイントに固定して比較する。OS の「Wi-Fi アシスト」「ネットワークの自動切り替え」を切る。切れたときの場所と操作を記録する。移動中に切れて座ると戻るなら、ローミングでほぼ確定です。

ネットワーク切替時に切れる

Wi-Fi からモバイル回線へ、あるいは SIM を切り替えたときに切れるのは、それ自体は正常な現象で、トンネルを張り直す必要があります。確認すべきは自動で再接続するかどうかです。クライアントで「ネットワーク変更時に自動再接続」といった項目を探して有効にします。OS によってはネットワーク切替後に接続の許可が取り消されるため、もう一度確認が必要になります。

記録してこそ役に立つ

3回切れればパターンは見えます。ただし記録が正しい場合に限ります。記録するのは4つ。時刻(分単位)、どれくらい続いたか、そのとき何をしていたか(放置か通信中か)、ネットワークを変えたか。これにクライアントのログの該当時刻の数行を加えれば、上のどれに当たるか判断できます。

クライアント側の4つのスイッチ

多くの切断問題は、この4つのスイッチで解決します。起動時の自動接続(再起動後に接続し忘れるのを防ぐ)、切断時の自動再接続(手動操作を減らす)、接続維持とキープアライブ(セッションの回収に対抗する)、使用時のみ接続(モバイルの省電力になるがバックグラウンドの継続性は犠牲になる)。4つは使い方に応じて取捨選択します。デスクトップなら最初の3つをすべて有効に、モバイルならバックグラウンド常駐が必要かどうかで4つ目を決めます。

上流側の問題と判断する目安

同じ回線が、別の端末・別のネットワークでも似た時刻に切れ、回線を変えれば直る。ここまで来て初めて上流を疑います。そのときは回線を変えたうえで、時刻を問い合わせに書き添えるほうが、再接続を繰り返すより役に立ちます。

購読の更新に失敗:リンクの整合性から取得経路まで確認

購読の更新とは、クライアントが購読 URL に1回リクエストを送り、設定テキストを受け取る処理です。失敗の原因は4種類しかありません。リンクが違う、リクエストが出ていかない、途中のページに横取りされる、クライアントが保存しそこねる。順に排除すれば、4ステップ以内に結論が出ます。

1. リンク全体をコピーし直す

   ユーザーパネルからコピーしてください。手で書き写したり、チャットアプリで一度転送されたテキストを使ったりしないこと。途中の改行や空白もそのままコピーされます。リンクにはパラメーターが含まれており、1文字欠けると設定を取得できません。

2. ブラウザで直接一度開いてみる

   正常な応答は、プレーンテキストかダウンロードファイルです。開いた先がログインページ、エラーページ、あるいは真っ白な画面なら、リンクが失効しているか、リクエストが途中のページに横取りされています。このステップが章の中で最も効果的です。

3. 先に接続してから更新する

   購読 URL 自体がトンネル経由でないと開けないことがあります。使える回線で先に接続してから、更新を押します。逆の順序だと「つながらないから更新できない、更新できないからつながらない」というループにはまります。

4. 古い購読を削除して追加し直す

   更新を何度も押すより確実です。クライアントによっては更新に失敗しても古い設定を残すため、更新に成功したように見えてノードが変わっていないことがあります。

コマンドラインを使う方は、1行のコマンドで経路が通るか確認できます。

curl -sS -m 15 "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

例のアドレスはダミーで、コマンドの形を示すためのものです。実際のリンクはパネルからコピーしてください。コマンドがテキストを返せば経路も内容も正常、HTML を返せば途中のページに横取りされており、そのままタイムアウトすればリクエストが出ていません。3つの結果が3つの対処方針に対応します。

更新は成功したのにノードが減る、または空になる

減った場合。回線プールは運用に合わせて増減するので、数が変わるのは正常です。よく使う地域が残っていれば、対応は不要です。

空になった場合。たいていはエラーページを受け取っており、クライアントがノードを1つも解析できていません。ステップ2に戻り、ブラウザでリンク自体を確認してください。

ブラウザでも開けない場合。問題はアカウント側にあります。パネルにログインしてプランの状態と残り通信量を確認してください。

複数端末で1つのリンクを共有する

本サービスは同時接続の台数に制限がなく、同じ購読リンクを複数の端末にインポートできます。端末ごとに個別に申請する必要はありません。注意が必要なのは、複数の端末で購読を何度もリセットしないことです。クライアントによってはリセットが旧設定を無効にし、他の端末まで使えなくなります。設定を変えるときは、新しいリンクを先にインポートして使えることを確認してから、古いものを削除してください。

時刻のずれも更新失敗の原因になる

HTTPS のリクエストは証明書の有効期間を検証します。システム時刻が大きくずれていると証明書の検証がそのまま失敗し、クライアントは更新失敗としか表示せず、詳細は何も出ません。システム時刻を自動同期に設定し、クライアントを再起動してもう一度試す。これがこの種の問題の唯一の対処法です。

特定のアプリだけプロキシを通らない:まずシステムプロキシに従うかを見る

ブラウザは正常で特定のアプリだけだめなら、トンネル自体は通っており、問題はそのアプリのリクエストの出し方にあります。アプリのネットワーク挙動は3種類です。システムプロキシに従う、自分で直接つなぐ、UDP を使う。どれに当たるかを先に判断し、そのうえで引き継ぎ方を決めます。

3種類のアプリ

システムプロキシに従う。ほとんどのブラウザと一部のデスクトップアプリがこの種類です。システムプロキシを有効にすれば、そのまま従います。

自分で直接つなぐ。ゲームランチャー、ソフトのアップデーター、コマンドラインツールの多くはシステムプロキシの設定を読みません。仮想 NIC(TUN)モードで全体の通信を引き継ぐ必要があります。

UDP や QUIC を使う。一部のブラウザや動画アプリは既定で QUIC を使います。トンネルの UDP 対応が弱いと、エラーではなく停止として現れるため、このアプリは使えないと誤解しやすくなります。

プラットフォームごとの違い

対処の順序

1. TUN モードに切り替える

   最も広い範囲をカバーする引き継ぎ方で、システムプロキシを読まないアプリにも効きます。切り替えたら対象のアプリを再起動して試します。

2. アプリの QUIC と HTTP/3 を無効にする

   ブラウザには通常無効化する項目があります。無効にすると通信は TCP に戻り、トンネル側の扱いが格段に安定します。

3. アプリが独自の DNS を使っていないか確認する

   一部のアプリは独自の暗号化 DNS を内蔵し、システム設定を迂回します。アプリの「セキュア DNS」を無効にし、システムに従わせます。

4. コマンドラインツールではプロキシを明示指定する

   クライアント画面でローカルポートを確認し、環境変数に書くか、コマンドに引数を足します。バックグラウンドサービスは別途設定が必要で、ユーザーの環境変数は継承しません。

5. アプリ別プロキシのリストを確認する

   Android などアプリ別プロキシに対応した環境では、対象のアプリがリストでチェックされていないと直結になります。

コマンドラインツールがトンネルを通っているかは、ステータスコードだけを出力するコマンドで確かめるのが一番直接的です。

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

200 が返ればそのコマンドの通信は通っており、000 なら通っていません。プロキシを有効にする前と後で1回ずつ実行し、結果を比べます。同じ方法は、あるスクリプトやビルドツールがトンネルを通っているかの判断にも使えます。

それでも通らない場合

アプリが IP を直書きしている、または独自プロトコルを使っている。こうした通信は分割ルールを迂回するため、TUN モードでまとめて引き継ぐしかありません。

アプリに独立したネットワーク権限がある。モバイルでは OS がアプリごとにネットワーク権限を制限していることがあり、システム設定で許可します。

アプリ自体の地域制限。出口を変えてもアカウントの地域が変わっていなければ、アプリはサービスを拒否します。これはトンネルとは関係ありません。

開発用途の長い接続(補完リクエスト、パッケージマネージャー、モデル API)は安定性への要求が高くなります。回線選びと分割の詳細はAI コーディングツールのネットワークと回線の解説をご覧ください。

モバイルのバックグラウンド切断:省電力設定が回線より原因になりやすい

画面をロックして数分で接続が消え、解除するとつなぎ直しになる。この種の問題は9割が回線ではなく、OS のバックグラウンド管理です。省電力のために、モバイル OS はバックグラウンドプロセスを凍結し、ネットワーク設定を回収し、バックグラウンド通信を制限します。まずプラットフォームごとにシステム設定を扱い、そのあとで回線を考えます。

iOS

低電力モード。有効にするとバックグラウンド更新とネットワーク活動が制限され、トンネルが真っ先に影響を受けます。無効にしてからもう一度テストします。最も見落としやすい項目です。

バックグラウンド App 更新。無効にすると、アプリはバックグラウンドで接続を維持できません。システム設定でこのクライアントだけ有効にします。

オンデマンド接続。有効にすると、ネットワークが必要になった時点で OS がトンネルを自動で立ち上げるので、手動で接続を押す必要がありません。モバイルで最も手間が少ないスイッチです。

ネットワークの切り替え。Wi-Fi の電波が弱いと OS がモバイル回線に切り替え、その過程でトンネルが張り直されます。特定の部屋に行くたびに切れる、という形で現れます。どちらか一方のネットワークに固定して比較すれば確認できます。

Android

バッテリー最適化。OS は使用頻度の低いアプリを制限状態に置き、バックグラウンド通信を切ります。クライアントをバッテリー最適化の除外リストに入れ、バックグラウンド動作を許可します。

自動起動の権限。一部のカスタム OS は既定でアプリの自動起動を禁止しており、再起動後に接続が自動で戻りません。アプリ管理で個別に許可します。

最近使ったタスクから消す。多くの OS では、アプリごとトンネルも終了します。バックグラウンド常駐が必要な場合は、マルチタスク画面でこのアプリをロックしてください。

共通チェックリスト

1. OS の省電力最適化からこのアプリを除外する

   スマート省電力、ディープスリープ、バックグラウンド制限といった項目を1つずつ確認します。

2. バックグラウンドデータとバックグラウンド動作を許可する

   OS のデータセーバーもバックグラウンド接続を切るため、個別に許可が必要です。

3. デュアル SIM はデータ用 SIM を固定する

   2枚の SIM を行き来するとトンネルが何度も張り直されます。データ用を1枚に固定すると安定します。

4. 別の端末で比較する

   同じネットワークで別の端末が切れないなら、原因は回線ではなく本機のシステムポリシーとほぼ判断できます。

省電力の問題ではないケース

ロック解除中でも頻繁に切れるなら、第5章に戻って時間パターンを見ます。Wi-Fi を変えたときだけ切れるならローミング。特定のアプリを前面に出したときだけ切れるなら、そのアプリがネットワークを奪っているか DNS を書き換えています。接続アイコンは出たままだがバックグラウンドのダウンロードが止まるなら、トンネルではなく OS がバックグラウンド通信を制限しています。

この4つを切り分ければ、システム設定をあちこち変えても効かない、という状態を避けられます。モバイルの省電力ポリシーはバージョンごとに変わります。OS のメジャーアップデート後に新しい切断パターンが出たら、まずこの章に戻ってチェックリストをやり直してください。

DNS 異常:ping は通るのに名前解決できない

DNS はドメイン名を IP アドレスに変換する役割を担います。これが不調になると、症状は断線そっくりになります。ブラウザは「サーバーが見つかりません」と表示するのに、IP に直接 ping を打つと通る。判定は簡単です。まず IP に ping、次にドメインに ping。2つの結果を比べれば一目で分かります。

ping -c 4 1.1.1.1
nslookup example.com
nslookup example.com 8.8.8.8

1つ目が通って2つ目が失敗するなら本機の DNS の問題、1つ目も2つ目も通って3つ目が失敗するなら本機の DNS が書き換えられているか誤った結果をキャッシュしています。3つすべて失敗するならネットワーク自体がつながっていない可能性が高く、第2章に戻ります。Windows では ping -c 4 を ping -n 4 に読み替えてください。

よくある症状の対応表

キャッシュを消す

設定を変えたらまずキャッシュを消します。そうしないと古い解決結果がしばらく有効なまま残ります。各プラットフォームのコマンドは次のとおりです。

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

モバイルにはコマンドラインがないため、機内モードを一度オン/オフすれば OS が名前解決をやり直します。

なぜ漏れるのか

複数のネットワークサービス。OS には有線、Wi-Fi、仮想 NIC など複数のネットワークサービスが同時に存在することがあり、プロキシはそのうち1つしか変えていません。解決要求は別のサービスから出ていきます。

ブラウザ内蔵の暗号化 DNS。ブラウザは独自に暗号化 DNS サーバーを指定でき、システム設定を完全に迂回します。切り分けのときはまずこれを切ります。

分割ルールが DNS を直結と判定している。ルールにドメインのマッチだけを書き、解決要求自体をカバーしていないと、解決はローカル側に出てしまいます。

切り分け手順のまとめ

まずトンネル内解決が有効か確認し、次にキャッシュを消し、ブラウザとシステムの暗号化 DNS を切り、最後に分割ルールを確認します。4ステップやっても解決に失敗するなら、2つの nslookup の出力を問い合わせに添えてください。自分で推測を続けるよりずっと早く進みます。

C6VPN のプライバシーポリシーは匿名・ログなしです。閲覧内容やアクセス先は記録しません。DNS をトンネル内で解決するのはこの方針の一部であり、切り分けの際も解決をローカルの回線事業者に渡さず、トンネル側で行うことを優先します。

複数端末・同時利用と問い合わせの目安

この章では2種類の話題を扱います。複数端末を同時に使ったときの挙動と、どこで自己確認をやめて問い合わせに移るかの目安です。

台数無制限の意味

同時接続の台数に制限はなく、同じアカウントで Windows、macOS、iOS、Android、Linux に同時にログインできます。端末ごとに個別に購入する必要はありません。この点は料金プランページにも記載しています。

ただし台数無制限は、端末ごとに帯域が専有されるという意味ではありません。出口の帯域は共有なので、複数の端末で同時に 4K を見たり大容量ファイルを落としたりすれば、互いに圧迫します。確認は簡単です。他の端末を切ってもう一度測り、速度が戻れば同時利用による圧迫であって、回線が悪くなったのではありません。

ルーター側でのプロキシはもう1つの使い方です。購読をルーターにインポートすると、家じゅうの端末が1つの出口を共有します。手間が減るのが利点ですが、すべての端末が同じ出口 IP になるため、サイト側の判定に引っかかると一緒に影響を受け、切り分けでもどの端末の問題か分かりにくくなります。まず単体で回線が使えることを確認してから、ルーターに載せるかを決めるのがおすすめです。

「デバイス数の上限に達しました」と表示された場合

本サービスのアカウント側に端末数の制限はありません。クライアントにそのような表示が出た場合は、まずどこからの表示かを見ます。多くは、同じ端末で2つのクライアントが同時に動いてローカルポートを取り合っているか、ルーターのプラグインが同時接続数に制限をかけているケースです。対処は、余分なクライアントを終了し、ルータープラグインの同時接続設定を確認し、パネルにログインし直して購読をコピーします。

問い合わせに移る目安

次の5つのうち2つ以上当てはまるなら、試し続けるより問い合わせに切り替える価値があります。

• 異なる地域・異なる回線タイプの3本がすべてつながらない
• 2つの異なるネットワーク(自宅回線とモバイル回線)で同じように失敗する
• システム時刻は合わせ済みで、他のプロキシ系ソフトもすべて終了済み
• 購読リンクはブラウザで開けるのに、クライアントでは更新に失敗する
• 同じ回線が別の端末では正常なのに、本機では必ず失敗する

問い合わせに添付する情報

添付すべきでないもの

アカウントのパスワード、購読リンクの全体、支払い証憑のスクリーンショット、身分証明書。これらは原因の特定に役立たず、漏えいの範囲を広げるだけです。購読リンクを示す必要がある場合は、token の部分を塗りつぶしてください。

窓口とその後の流れ

問い合わせはユーザーパネル内から送信できます。ログインして問い合わせページに進んでください。送信前に使い方を一度ご覧ください。いくつかの問題はそこで解決します。現在利用できる連絡方法はお問い合わせ・サポートページでも確認できます。

切り分けの結果、サービスが期待に合わないと判断された場合は、パネル内から30日間の理由不問返金を申請できます。登録自体にメールアドレスは不要で、ユーザー名とパスワードだけで完結します。これは返金の手続きでも同じで、メールが見つからずに止まることはありません。