このページは体系的なリファレンスであり、導入ガイドではありません。登録・購入・初回接続がまだ済んでいない場合は、まずはじめてのガイドで 5 つのステップを終えてから戻ってきてください。本ページは症状別の章立てで、各章に判断の順序、自分で実行できる確認手順、対応する解決策、そして作業を止めて問い合わせるべきケースを示します。章の間に厳密な順序はありません。起きている症状の章を開いてください。
診断の前に:4層の経路を切り分ける
接続サービスの不調は現れ方がさまざまですが、原因の位置は 4 つしかありません。層ごとに見れば、クライアントを何度も再起動するより速く、無関係な設定に時間を取られることもありません。4 層は近い順に、端末側のネットワーク、クライアントによる通信の引き受け、サブスクリプションとアカウント、出口ノードです。
4 層がそれぞれ担うもの
- 端末のネットワーク層。端末からルーター、ルーターから回線事業者まで。ここが切れるとどの回線でもつながらず、すべてのサイトが開かない状態になります。
- クライアント層。クライアントのプロセスが実際に通信を引き受けているか、システムプロキシが有効か、振り分けルールがどう判定しているか。ここで問題が起きると、接続済みと表示されるのにアプリがプロキシを通らない状態になります。
- サブスクリプションとアカウント層。サブスクリプション URL のトークンが有効か、回線リストが最新か、プランが有効期限内か。ここで問題が起きると、回線リストが空になったり更新に失敗したりします。
- 出口ノード層。接続先ノードから目的サイトまでの経路。ここで問題が起きると、特定の地域や特定のサイトだけ使えない状態になります。
判断は近い層から遠い層へ。まず端末が普通にインターネットにつながるか、次にクライアントが通信を引き受けているか、その次にサブスクリプションとアカウントの状態、最後にノードを疑います。逆の順で進めると、ローカルネットワークの問題をノードの問題と勘違いし、すべての回線を試しても解決しない、というのがよくある結末です。
30 秒チェック
クライアントを終了し、中国本土のサイトを開きます。開けば端末のネットワークは正常なので先へ進みます。開けなければ端末のネットワークを先に直してください。以降の手順は不要です。単純すぎるように見えますが、実際の切り分けでは「つながらない」の少なからぬ部分がここに落ち着きます。ルーターの停止、回線料金の未払い、公衆 Wi-Fi のポータル認証などです。
3 つのコマンドで経路を見る
GUI では分からないとき、コマンドラインにはより具体的な情報が出ます。以下のコマンドは各 OS に標準で入っており、追加インストールは不要です。
| プラットフォーム | コマンド | 確認する内容 |
|---|---|---|
| Windows | ipconfig /all | デフォルトゲートウェイと DNS サーバーが空でないか |
| Windows | ping www.example.com | アドレスを解決できるか、パケットロスはないか |
| Windows | tracert www.example.com | 何ホップ目からタイムアウトするか |
| macOS / Linux | ip addr または ifconfig | ネットワークインターフェースが有効か、アドレスを取得しているか |
| macOS / Linux | ping www.example.com | 解決結果と疎通性 |
| macOS / Linux | traceroute www.example.com | 経路のどこで切れているか |
コマンド内の www.example.com は、アクセスしたい任意のドメインに置き換えられます。ドメインへの ping が失敗し、既知のアドレスへの ping は通る場合、問題は経路ではなく名前解決にあります。DNS の章へ進んでください。
一度に変えるのは 1 つだけ
切り分けで最も多い誤りは、回線の変更・プロトコルの変更・クライアントの再インストールを同時にやってしまうことです。うまくいっても何が効いたのか分からず、だめでもどこまで戻せばよいか分かりません。正しいやり方は、現在の状態を記録し、1 項目だけ変えてすぐ再テストし、だめなら元に戻すことです。この習慣は問い合わせのときにも役立ち、サポートが同じ環境を再現できます。
まず証拠を残してから動く
クライアントには通常、接続ログや診断の入口があります。不調が出たらまずログを書き出すかスクリーンショットを撮ります。とくにエラーメッセージの原文が重要です。再インストールするとローカルのログは消えるので、順序は証拠を残してから再インストールを検討する、です。問い合わせで最も価値があるのは、エラー原文、発生時刻、すでに試した手順の 3 つです。
まったくつながらない:エラーが出る、または読み込みが続く
まず 2 つの現れ方を切り分けます。1 つはクライアントが接続失敗・接続タイムアウトを明示する場合で、ハンドシェイクの段階で失敗しており原因は比較的はっきりしています。もう 1 つは接続中のまま何のフィードバックもない場合で、経路でパケットが落ちているかクライアントのプロセスが固まっている可能性が高いです。前者はエラー表示から、後者はネットワーク環境から調べます。
4 ステップで特定
- 端末のネットワークを確認。クライアントを終了し、中国本土のサイトを開きます。開けなければ端末のネットワークを先に直します。LAN ケーブル、Wi-Fi 接続、ルーターのランプ、公衆ネットワークのポータル認証などです。
- 回線を変えて再試行。クライアントで別の地域の回線に切り替えます。すべての回線で失敗するなら原因はアカウントかサブスクリプションの層です。一部の回線だけ失敗するなら、別の回線に変えれば済み、それ以上いじる必要はありません。
- ネットワークを変えて再試行。別のネットワークで一度接続します。ネットワークを変えるとつながるなら、元のネットワークが特定のポートやプロトコルを制限しているのであり、アカウントの問題ではありません。
- アカウント状態を確認。ユーザーパネルにログインし、サブスクリプションが有効期限内か、通信量を使い切っていないかを見ます。月額プランの通信量は契約日ごとに毎月リセットされます。トラフィックパックは使い切るまで有効で、期限はありません。
よくある原因の対照
4 ステップで特定できないときは、次の表を上から順に試してください。
| 現象 | 最も考えられる原因 | 対処 |
|---|---|---|
| 接続が即座に失敗し、タイムアウトと表示される | 端末の時刻が大きくずれている | 時刻の自動設定を有効にして再試行 |
| 以前は使えたが、更新後はだめ | クライアントのバージョンが古い | パネルのダウンロードページから最新クライアントに変更 |
| この端末だけつながらない | セキュリティソフトによるブロック | クライアントを信頼リストに追加 |
| 社内・学内ネットワークではすべて失敗 | ネットワークが TCP のみ許可 | TCP 対応の回線に切り替え |
| 認証失敗と表示される | サブスクリプションの期限切れ、またはトークンのリセット | パネルでサブスクリプション URL を再コピー |
| 端末を変えても失敗 | アカウント状態の異常 | パネルでサブスクリプションと通信量を確認 |
システム時刻は最も見落とされやすい項目
暗号化ハンドシェイクは時刻に敏感です。端末の時刻が標準時刻と数分ずれるだけで証明書の検証に失敗し、接続直後に切れる、あるいはハンドシェイクがタイムアウトする形で現れます。ノート PC を長期間ネットにつないでいない、マザーボードの電池が劣化している、タイムゾーンを手動で変えた、といった場合にずれが生じます。OS の時刻自動設定をオンにし、同期が終わってから再試行してください。
セキュリティソフトとシステムプロキシの残留
一部のセキュリティソフトは、とくに初回実行時にクライアントプロセスの通信を遮断します。症状は、クライアントは接続済みと表示されるのに通信が出ていかないというものです。クライアントを信頼リストや許可ルールに追加して再試行してください。もう 1 つは、前回の異常終了でシステムプロキシの設定が残り、すでに存在しないローカルポートを指したままになっているケースです。システム設定でプロキシをオフに戻し、あらためてクライアントに引き受けさせてください。
4 ステップと対照表を試しても問題が安定して再現し、ネットワークを変えても端末を変えても同じ結果なら、ローカル環境の問題ではないとほぼ判断できます。最後の章のチェックリストに沿って情報を整理し、問い合わせてください。
接続できるのにページが開かない
クライアントは接続済みと表示されるのに、ブラウザは読み込みが続き、「このサイトにアクセスできません」や DNS 解決の失敗を表示する。この種の症状はノードの故障と誤判定されやすいのですが、実際には多くが通信の引き受け方や名前解決の設定の問題です。まず二分しましょう。すべてのサイトが開けないのか、一部のサイトだけ開けないのか。
すべてのサイトが開けない
通信がまったく出ていかないか、出たが戻ってきていない状態です。次の 3 点を順に確認します。
- システムプロキシが有効か。Windows なら設定の「ネットワークとインターネット」でプロキシを確認します。クライアントを起動しているときはローカルアドレスとポートが見えているはずです。オフ表示で、クライアントがシステムプロキシモードなら、引き受けに失敗しています。
- クライアントが TUN モードか。TUN モードはネットワークインターフェースの通信を直接引き受けるため、システムプロキシがオフ表示でも正常です。この場合はクライアント自身の接続状態と通信カウントが増えているかを見ます。
- MTU が合っているか。接続はできるのに大きなパケットが落ちると、ページが途中まで読み込まれて止まり、最後にタイムアウトします。クライアントの MTU を 1 段階小さくして再試行してください。
一部のサイトだけ開けない
通信は出ているものの、振り分けルールが目的サイトを直接接続と判定しているか、目的サイト側が地域によってリクエストを拒否しています。まずクライアントをグローバルモードに切り替えて検証します。グローバルで開けるならルールの問題、グローバルでも開けないなら目的サイトか回線地域の問題です。
ルールモードでは、クライアントはドメインやアドレスごとにプロキシを通すかどうかを決めます。サイトによっては複数のドメインを使っており、メインドメインはプロキシを通るのに静的リソースのドメインが直接接続と判定され、ページの構造だけ読み込まれてスタイルや画像が欠けることがあります。その場合は該当サイトをプロキシのルールに追加するか、一時的にグローバルモードを使ってください。
まずブラウザ側を除外する
シークレットウィンドウで同じサイトを開きます。シークレットでは開けて通常ウィンドウでは開けないなら、キャッシュか HSTS の記録が原因なので、キャッシュを一度消せば解決します。また、ブラウザ内蔵のセキュア DNS はシステムの名前解決を迂回し、振り分けルールを無効にしてしまいます。切り分けの間はオフにしてください。
| 現象 | 最も考えられる原因 | 1 ステップ検証 |
|---|---|---|
| すべてのサイトが開けず、クライアントは接続済みと表示 | システムプロキシが有効になっていない | グローバルモードに切り替えて再試行 |
| DNS 解決の失敗と表示される | 名前解決がトンネルを通っていない | リモート解決を有効にする |
| 特定のサイトだけ開けない | 振り分けルールが直接接続と判定 | グローバルモードで検証 |
| ページが途中まで読み込まれて止まる | MTU の不一致 | MTU を小さくする |
| シークレットウィンドウなら正常 | ブラウザのキャッシュまたは HSTS | キャッシュを消去 |
出口地域を確認する
サイトによっては開けないのではなく、開いたうえで地域が利用できないと表示されます。これは故障ではなく、出口地域がサイトの要件と合っていないためです。クライアントの接続詳細で現在の出口地域を確認し、目的サイトが対応する地域に切り替えてください。ストリーミングと AI ツールは地域判定がとくに厳しく、詳しくはサイト内のAI 高速化特集をご覧ください。
速度低下と夜間の混雑
遅いといっても少なくとも 3 種類あり、対処法はまったく違います。ページ表示が遅いのは最初のバイトまでの時間が長い場合で、通常は遅延が大きいか名前解決が遅いのが原因です。ダウンロードが遅いのは持続速度が出ない場合で、通常は帯域の制限か経路の混雑です。動画が固まるのは画質が落ちて頻繁にバッファリングする場合で、通常は帯域は足りているがジッタが大きい状態です。まずどれかを切り分けてから対処してください。
まず区間ごとに測る
- クライアントなしで基準を測る。直接接続で端末から中国本土のサイトまでの速度を測り、結果を記録します。
- クライアントありで測る。最も近い地域に接続して、もう一度測ります。大きく落ちるなら、その回線のローカルまでの経路品質が普通ということです。
- 同じ地域の別タイプに変えて測る。同じ地域には専用線、中継、直接接続などの種類があることが多く、それぞれ測ると差がはっきり出ます。
速度測定中は、バックグラウンドのダウンロード、クラウドストレージの同期、OS の更新を止めてください。速度測定ソフトの瞬間的なピークは参考になりにくく、1 分間の平均ダウンロード速度のほうが実際の体感に近くなります。
夜間の混雑は物理現象
20:00 から 23:00 は国際回線が最も混み合う時間帯です。この時間は国際出口の公共帯域を多くの利用者が共有するため、遅延が増え、パケットロスも増え、どのサービスも避けられません。違いが出るのは回線の種類です。専用線は独立したチャネルを使い、公共出口と帯域を取り合わないため、混雑時間帯でも比較的安定します。中継はまず中継ノードを経てから国外に出る方式で、コストが低い代わりに混雑時間帯の変動は専用線より大きくなります。直接接続は公共インターネットの出口をそのまま使うため価格は最も低く、混雑時間帯には最も不安定です。
| 回線タイプ | 経路 | 用途 | 混雑時間帯の挙動 |
|---|---|---|---|
| IEPL 専用線 | 独立チャネルで出口まで直通 | 4K 動画、長時間の会議、大容量ファイル転送 | 比較的安定 |
| 中継 | ローカル → 中継ノード → 出口 | 日常のブラウジング、SNS、軽い動画視聴 | 変動あり |
| 直接接続 | 公共インターネット出口 | 一時的な調べもの、軽い利用 | 変動が大きい |
夜間に 4K を見る、長時間の会議をするのが主な用途なら専用線タイプを優先してください。日中に調べものをするだけなら直接接続でも十分です。回線ページでは 90+ の国・地域 / 220+ の回線を地域別に掲載しており、用途から選べます。
ローカルでできる最適化
- 有線を優先。Wi-Fi は 2.4GHz 帯が干渉を受けやすいので、LAN ケーブルを挿せるなら挿してください。
- 2 つの周波数帯を分ける。ルーターが 2.4G と 5G を同じ名前でまとめていると、端末が 2.4G につながることがあります。名前を分けて 5G に手動で接続してください。
- プロトコルを変える。同じノードでもプロトコルによって耐干渉性が異なり、特定のネットワークで速度制限を受けたプロトコルも、別のものに変えると回復することがあります。
- バックグラウンドの使用を止める。OS の更新、クラウドストレージの同期、オンラインバックアップはバックグラウンドで帯域を使います。
- ブラウザの負担を減らす。広告ブロック拡張を入れすぎたり、タブを何十個も開いたりすると、ページが遅く感じます。
4K と長時間会議の要件
4K ストリーミング配信では通常 10 数 Mbps から 20 数 Mbps の安定した帯域が推奨されます。ポイントはピークではなく安定であることです。ビデオ会議は遅延とジッタがより重要で、帯域が足りていてもジッタが大きければ、やはり映像が固まり音が途切れます。どちらの用途も、速度測定の数値だけで判断せず専用線タイプを優先してください。
感覚より記録が確か
同じ回線でも時間帯によって挙動は大きく変わります。朝、夜、深夜にそれぞれ測って結果を記録し、回線の問題か時間帯の問題かを判断してください。この記録は問い合わせのときにも最も役立つ材料の 1 つで、「なんとなく遅い」よりはるかに具体的です。
頻繁な切断とモバイルでのバックグラウンド切断
切断は 2 種類あります。デスクトップで一定時間ごとに切れる場合と、モバイルでバックグラウンドに回してしばらくすると切れる場合です。原因はまったく違うので分けて対処します。
デスクトップの定期的な切断
- システムのスリープ。PC がスリープから復帰すると、接続は通常作り直しが必要です。クライアントに復帰後の自動再接続オプションがあるか確認してください。
- ネットワークアダプターの電源管理。Windows は既定で省電力のためにアダプターをオフにできるようになっており、オフになると接続も切れます。デバイスマネージャーでこの項目を解除してください。
- ルーターのセッションタイムアウト。長時間通信がないと、ルーターはセッションテーブルの項目を回収します。クライアントのキープアライブ(ハートビート)機能を有効にしてください。
- Wi-Fi ローミング。自宅に複数のアクセスポイントがあると、端末がアクセスポイント間を切り替える際に一時的に切れます。
- 回線事業者の定期的な再接続。一部の回線は 24 時間ごとに再接続し、切断時刻が固定されます。時刻を照らし合わせて確認できます。
モバイルのバックグラウンド切断
iOS も Android もバックグラウンドでネットワーク活動を回収します。これは OS の省電力ポリシーであり、クライアントの故障ではありません。バックグラウンドで接続を維持するには、クライアントを OS のホワイトリストに追加する必要があります。
| プラットフォーム | 確認する設定 | 説明 |
|---|---|---|
| Windows | ネットワークアダプターの電源管理、スリープ設定 | 「コンピューターがこのデバイスをオフにできる」を解除 |
| macOS | 省電力設定、ネットワークサービスの順序 | 復帰後にクライアントが再接続しているか確認 |
| iOS | バックグラウンド App 更新、低電力モード | 低電力モードはバックグラウンドの通信を制限します |
| Android | バッテリー最適化、バックグラウンド動作の権限 | クライアントを制限なしに設定 |
| Linux | ネットワークマネージャー、スリープ時のフック | 復帰後にクライアントのサービスを再起動 |
OS の設定以外に、よくある状況が 2 つあります。1 つはネットワークの切り替えで、Wi-Fi からモバイルデータに切り替えると接続の作り直しが必要になり、短時間の中断は正常です。もう 1 つは画面ロック後の切断で、一部の機種の省電力モードはロック後にバックグラウンドの通信を制限します。クライアントをホワイトリストに追加すると緩和できます。
クライアントだけの切断か、端末全体の切断かを切り分ける
切断が起きたとき、同時に中国本土のサイトを開きます。中国本土のサイトも開けないなら端末全体のネットワーク問題で、接続サービスとは関係ありません。中国本土のサイトは正常で、プロキシを通る通信だけが切れるなら、クライアントか回線の問題です。この一手間で調査範囲を半分に絞れます。
複数のプロキシツールを重ねない
安定させようとしてクライアントやプロキシツールを 2 つ同時に動かすのはよくある誤りです。互いにシステムプロキシ設定とルーティングテーブルを取り合い、どちらも不安定になり、ログも混ざってどちらの問題か分からなくなります。同時に動かすのは 1 つだけにしてください。
切断に一定の周期がある場合、たとえば 1 時間に 1 回なら、その時刻を記録してください。一定周期はシステムのタスク、ルーターのポリシー、回線事業者の動作を示すことが多く、ランダムな切断より特定しやすくなります。
サブスクリプション更新の失敗
サブスクリプション URL はトークン付きのアドレスで、クライアントがどの回線を取得し、どの出口を使うかを決めます。URL が無効になったり、途中で切れたり、遮断されたりすると更新に失敗します。詳しい仕組みはサイト内の記事「サブスクリプション URL とは:取得方法・インポート手順・更新頻度」をご覧ください。
まずエラーの種類を見る
| エラー表示 | 意味 | 対処 |
|---|---|---|
| 401 / 403 / トークンが無効 | URL が無効、またはリセットされた | パネルで完全な URL を再コピー |
| 接続タイムアウト | ネットワーク層が通らない、または遮断されている | ネットワークを変え、プロキシを切って再試行 |
| 解決失敗 / 形式エラー | 取得した内容が不完全 | 古いサブスクリプションを削除して再インポート |
| 更新は成功したがリストが空 | アカウントに利用可能な回線がない | サブスクリプションの状態と通信量を確認 |
対処の順序
- パネルからコピーし直す。チャット履歴、スクリーンショット、古いメールから写さないでください。1 文字欠けるだけで失敗します。
- 古いサブスクリプションを削除してからインポート。更新を押すだけでは、壊れたローカルキャッシュが上書きされないことがあります。
- 別のネットワーク状態で再試行。まずプロキシを切って更新し、切ると失敗するならプロキシをオンにして試します。この 2 つの状況は、サブスクリプション URL が直接接続を必要とするか、プロキシ経由を必要とするかに対応します。
- 端末の時刻を確認。時刻のずれは証明書検証の失敗を招き、URL が無効なときとよく似た症状になります。
- セキュリティソフトを確認。一部のセキュリティソフトはサブスクリプション URL へのリクエストを遮断します。
サブスクリプション URL の形式はおおよそ次のとおりです。これは例示でありそのままは使えません。実際の URL はユーザーパネルからコピーしてください。
https://example.com/sub?token=YOUR_TOKEN
URL は認証情報と同じ
サブスクリプション URL にはトークンが含まれ、入手されると回線を取得されます。公開グループやスクリーンショットに貼らず、問い合わせ本文にも書かないでください。漏えいが疑われる場合はパネルでサブスクリプション URL をリセットします。古い URL は即座に無効になり、クライアントは新しい URL で再インポートが必要です。リセット後、古い URL をインポート済みのクライアントは次回の更新で失敗しますが、キャッシュされた回線がリストに残り、接続はできるのに目的サイトにつながらない、という状態になることがあります。こうした挙動では、まずサブスクリプションを更新し、ノードの故障と早合点しないでください。
更新の頻度
クライアントは自動更新を設定でき、1 日 1 回で十分です。回線が調整されたら手動で 1 回更新してください。頻繁に更新しても回線が速くなるわけではなく、無駄なリクエストが増えるだけです。更新後に回線数が明らかに減った場合は、まずアカウント状態を確認し、そのうえでクライアントが古いデータをキャッシュしていないかを見てください。
更新は成功するのにつながらない
これは別の種類の問題です。サブスクリプション自体は正常なのに、取得した回線につながりません。第 1 章の 4 層の判断に戻り、まず端末のネットワークを確認してから回線を変えてください。すべての回線で失敗するのにサブスクリプションの更新は正常なら、アカウント状態とローカルネットワークの制限を重点的に調べます。
特定のアプリだけプロキシを通らない
システムプロキシと TUN モードでは対象範囲が異なります。システムプロキシ設定を読まないアプリ、OS に制限されているアプリ、独自にネットワークスタックを実装しているアプリがあるため、ブラウザは正常なのに特定のソフトだけつながらない、ということが起きます。
まずアプリがプロキシを通っているか確認
- クライアントのログを見る。接続ログを開き、そのアプリのリクエスト記録があるか見ます。記録があれば通信は入ってきており、問題は出口側です。記録がなければ通信は引き受けられていません。
- グローバルモードに切り替えて検証。グローバルモードではすべての通信がプロキシを通ります。これでつながればルールの問題、つながらなければアプリ自体がプロキシを使えないということです。
- 別の端末で検証。同じアカウントで別の端末から同じアプリを試します。両方だめなら回線かアプリの問題、片方だけだめならその端末の設定の問題です。
よくある 3 つのケース
システムプロキシを読まないアプリ。一部のデスクトップソフト、ゲームランチャー、アップデーターは下位のネットワークインターフェースを直接使い、システムプロキシ設定を読みません。TUN モードで通信全体を引き受けるのが解決策です。
アプリストア系アプリのループバック制限。この種のアプリは既定でローカルのループバックアドレスへのアクセスが許可されておらず、プロキシクライアントは通常ローカルで待ち受けています。OS 側でそのアプリにループバックの例外を設定しないと、ネットワークエラーが表示され続けます。
UDP を使うアプリ。音声通話、ゲーム、一部のビデオ通話は UDP を使います。現在の回線が UDP に対応していないと、これらの機能は失敗しますが、ウェブページは正常なままです。UDP 対応の回線に変えるか、アプリ内で QUIC を無効にしてください。
| 現象 | 原因 | 対処 |
|---|---|---|
| ブラウザは正常、デスクトップソフトだけつながらない | システムプロキシを読まない | TUN モードに切り替え |
| ストア系アプリがネットワークエラーを表示 | ループバック制限 | ループバックの例外を有効化 |
| ログインはできるがルームに入れない | UDP が通らない | UDP 対応の回線に変更 |
| ページは開けるがアプリは解決失敗と表示 | アプリ独自の DNS | リモート解決を有効にする |
| 地域が利用できないと表示 | 出口地域の不一致 | 対応する地域の回線に変更 |
ブラウザ拡張も干渉する
プロキシ系のブラウザ拡張の中にはシステムプロキシを上書きし、ブラウザと OS が別の出口を使う状態を作るものがあります。症状は、ブラウザでは開けるサイトがデスクトップソフトでは開けない、またはその逆です。切り分けのときはプロキシ系の拡張をすべて無効にし、クライアントだけを残してください。
地域判定が厳しい場面
ストリーミングと AI ツールは出口地域で利用可否を判定するため、回線の地域が合っていないと接続できても拒否されます。Midjourney は Discord 上で動作し、長時間接続は安定性の要求が高く、切断がそのまま画像生成の失敗につながります。詳しくはサイト内の記事「AI 画像生成ツールの高速化:Midjourney と Discord の接続実測比較」をご覧ください。ChatGPT などのツールは地域にさらに敏感で、利用できないと表示されたらまず地域を変え、そのあと他の原因を検討してください。
DNS 異常と名前解決のエラー
DNS はドメイン名をアドレスに変換する役割を担います。名前解決に問題があると、ネットワーク自体はつながっているのにドメイン名で開けない、という形で現れます。この種の故障はノードの故障と誤判定されやすいものです。
3 つの典型的な症状
- 名前解決のタイムアウト。ブラウザが長く読み込み、最後にアクセスできないと表示します。
- 誤ったアドレスへの解決。ドメインが無関係なアドレスに解決され、ページが開かないか別のサイトに飛びます。
- 一部のドメインだけ解決失敗。同じネットワークで開けるドメインと開けないドメインがある。
ローカル解決とリモート解決
プロキシを使わない場合、DNS クエリはローカルの回線事業者に送られます。プロキシを使う場合、クライアントがローカル解決に設定されていればクエリはやはり事業者に送られ、その結果が接続に使われるだけです。リモート解決に設定されていれば、クエリは出口ノードに送られ、出口側の DNS が解決するため、結果は目的サイトの実際の位置に近くなります。越境する場面では、ローカル解決で起こりうる干渉を避けられるため、リモート解決のほうが一般に信頼できます。
切り分けの手順
- コマンドラインで確認。
nslookup www.example.comで解決結果を見ます。macOS と Linux ではdig www.example.com +shortも使えます。 - プロキシのオン・オフで結果を比べる。プロキシを切ると誤ったアドレスに解決され、オンにすると正常なら、ローカル解決が干渉を受けています。リモート解決に切り替えてください。
- ブラウザのセキュア DNS を確認。ブラウザ内蔵のセキュア DNS はシステムの名前解決を迂回し、振り分けルールを無効にします。切り分けの間はオフにしてください。
- クライアントの DNS 設定を確認。リモート解決を優先してください。ローカル解決を使う必要がある場合は、システムの DNS を信頼できる公開 DNS サービスに変更します。
- キャッシュを消す。OS とブラウザの両方に DNS キャッシュがあるため、設定を変えたら一度消してください。
nslookup www.example.com
dig www.example.com +short
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache
前半 2 つは確認、後半 2 つはキャッシュの消去です。Linux では resolvectl flush-caches を使うか、ローカルの名前解決サービスを再起動します。
| 現象 | 原因 | 対処 |
|---|---|---|
| すべてのドメインで解決失敗 | ローカル DNS に到達できない | システム DNS を変更、またはリモート解決を有効化 |
| 一部のドメインだけ失敗 | 名前解決が干渉を受けている | リモート解決を有効にする |
| 誤ったアドレスに解決される | ローカル解決がハイジャックされている | リモート解決とキャッシュ消去 |
| プロキシを切ると正常、オンにすると失敗 | クライアントの解決設定の衝突 | 解決モードを調整 |
| ブラウザが解決エラーを表示 | ブラウザのセキュア DNS の衝突 | セキュア DNS を無効化 |
複数の設定変更ツールを重ねない
DNS を変更するツールを複数同時に入れると、互いに上書きし合い、設定は反映されたように見えて実際は変わっていない、という状態になります。切り分けのときは 1 つだけ残し、変更後にクライアントを再起動してください。
リモート解決を有効にし、キャッシュも消したのに一部のドメインだけ失敗する場合は、失敗したドメインと解決結果を記録し、発生時刻とあわせて問い合わせてください。この種の問題は特定ドメインの解決経路に関わるため、出口側での確認が必要です。
アカウント状態、端末数、問い合わせ
前の 8 章は接続と設定を扱いました。この章ではアカウント層と、切り分けを終えたあとに問題をどう引き渡すかを扱います。
端末数は制限項目ではない
本サービスは同時接続端末の台数を制限していません。Windows、macOS、iOS、Android、Linux で同時にログインして利用でき、端末を 1 台増やすためにプランを上げる必要はありません。そのため端末数の上限超過という表示は本サービスでは出ません。ログイン後に弾かれる場合は、同じアカウントで複数の場所から繰り返しログインしているか、パスワードを他人に知られている可能性が高いので、まずパネルでパスワードを変更してください。
アカウント状態の 3 つのケース
- サブスクリプションの期限切れ。月額プランは契約日ごとに毎月通信量がリセットされ、期限が切れると回線リストが空になったり接続できなくなったりします。
- 通信量の使い切り。月額プランの通信量を使い切ると、その月は使い続けられません。パネルで上位プランにアップグレードでき、差額は残り日数で按分されます。トラフィックパックを購入することもでき、こちらは使い切るまで有効で期限はありません。
- パスワードの問題。登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。パスワードを忘れた場合はパネルの再設定入口を使ってください。
月額プランは 3 段階で、¥9.9/月が 60GB、¥18/月が 250GB、¥28/月が 500GB です。トラフィックパックも 3 段階で、¥158/300GB、¥358/1000GB、¥658/3000GB です。支払い方法は Alipay、WeChat Pay、USDT に対応しています。価格と容量はプランページを正としてください。
問い合わせに切り替えるべきタイミング
前の章の手順をひととおり試して、次のいずれかに当てはまるなら、それ以上は自分で試さないでください。
- 問題が安定して再現し、ネットワーク、端末、回線を変えても結果が同じ。
- アカウント状態が実際と合わない。たとえば支払い済みなのに未開通と表示される、通信量の集計が明らかにおかしい。
- サブスクリプション URL をリセットしても更新できない。
- クライアントのログに安定したエラーコードがあり、対照表の対処がすべて効かない。
問い合わせに添える情報
| 必須項目 | 説明 |
|---|---|
| プラットフォームと OS | Windows / macOS / iOS / Android / Linux、および OS のメジャーバージョン |
| クライアント | クライアント名とバージョン番号。「バージョン情報」で確認できます |
| 回線 | 問題発生時に使っていた地域と回線タイプ |
| 時刻 | エラーが起きた具体的な時刻。タイムゾーンを明記 |
| エラー原文 | そのままコピーするかスクリーンショットを添付。「つながらない」だけにしない |
| 実施済みの手順 | 試した確認項目と結果を列挙 |
| 再現範囲 | ネットワーク、端末、回線を変えても同じか |
サブスクリプション URL の全文、パスワード、支払いスクリーンショット内の完全な注文番号は添付しないでください。注文について説明する必要がある場合は、注文時刻と金額だけで足ります。
返金とその後の流れ
本サービスは 60 日間の無条件返金に対応しています。初回のお支払いから 60 日以内に申請でき、問い合わせに注文情報を書けば済みます。問い合わせを送ったあとは、現在の状態を固定して設定を変えないでください。サポートが同じ環境で再現しやすくなります。最終的にローカルネットワークの問題だと判明した場合も、問い合わせに残した記録は同じ状況に陥った次の人の役に立ちます。