VPNトラブルシューティングガイド

「接続できない」状況を切り分ける

接続できない原因には、クライアントが起動しない、サブスクリプションにルートが表示されない、選択したルートが接続中のまま進まないなどがあります。これらは同じ原因とは限りません。画面に表示された文言を記録し、ソフトの起動時、設定の更新時、接続確立時のどの段階で問題が起きるか確認してください。クライアントにルートが読み込まれていない場合は、サブスクリプション更新の項目を先に確認します。この状態でプロキシモードを何度切り替えても、欠けている設定は補えません。

次にクライアントの接続を切り、現在のネットワーク自体が使えるか確認します。ブラウザーで普段から直接アクセスできるサイトを開き、ネットワークへのログイン画面が未完了のままになっていないかも確認してください。ホテル、出張先、公共のネットワークでは、ブラウザーで利用規約への同意が必要な場合があります。通常のネットワーク接続が確立していなければ、クライアントも外部へ接続できません。この結果だけでサブスクリプションの無効化を判断したり、急いでアカウントを削除したり再決済したりする必要はありません。

特定ルートの問題か、接続環境全体の問題かを切り分ける

ユーザーパネルでサブスクリプションの状態、残りのデータ容量、有効期限を確認してから、クライアントで設定を手動更新します。月額サブスクリプションのデータ容量は契約開始日を基準に毎月リセットされ、暦月の初日に一律でリセットされるわけではありません。データパックは使い切るまで有効で、期限切れになりません。アカウントに問題がなければ、現在のエラーを記録し、別の地域または別タイプのルートを選んでください。ネットワーク環境は変えず、ルートだけを変更すると、結果がルートの違いによるものか判断しやすくなります。

特定のルートだけ失敗し、ほかのルートでは同じサイトを開ける場合は、そのルートと現在のネットワークの組み合わせを調べます。地域、ルート名、タイプを記録し、接続できる代替ルートを一時的に利用してください。すべてのルートで失敗する場合は、同じルートを選んだまま、別の利用可能なネットワークで比較します。ネットワークを変えて復旧した場合、元の接続環境、認証状態、ネットワークポリシーを確認する手がかりになります。ただし、それだけでサーバー側の状態を断定することはできません。

権限、プロキシ設定の残留、セキュリティ警告を確認する

システムがクライアントによるネットワーク設定の追加を許可しているか、関連するバックグラウンドコンポーネントが無効になっていないか確認します。システムの許可ダイアログが表示されたら、要求元が使用中のクライアントであることを確かめてから、プラットフォームの案内に従ってください。見知らぬサイトから修復用コンポーネントと称するファイルをダウンロードしないでください。以前ほかのプロキシソフトを使っていた場合は、正常に終了し、システムプロキシの設定が残っていないか確認します。複数のツールが同時にネットワークを制御すると、停止済みのローカル接続先にリクエストが送られることがあります。

セキュリティソフトが通信をブロックした場合は、保護機能全体を無効にするのではなく、対象、ファイルパス、理由を確認します。会社管理の端末には統一されたネットワークポリシーが設定されている場合があり、個人で変更できない設定は端末管理者に確認してください。クライアントからサービスやドライバーの起動失敗が表示されたら、いったん完全に終了して再起動し、システムの指示に従って許可を与え直します。再インストールはその後の手段です。実行前にサブスクリプションを再取得できることを確認し、必要な診断情報を保存してください。

確認する順番：通常のネットワーク → アカウント状態 → 設定の読み込み → 個別ルートの比較 → 接続ネットワークの比較 → システム権限。各段階の結果を残し、異なる問題を混同しないようにしましょう。

端末側での試行を止めて問い合わせるタイミング

通常のネットワークに問題がなく、アカウントが有効で、設定の更新も成功しているのに、異なる地域のルートが複数のネットワークで同じエラーになる場合は、問い合わせを検討してください。クライアントとOSの情報、エラー全文、発生した段階、実施済みの比較結果を添えます。証明書や端末時刻に関するエラーが明示されている場合は、システムの日付、時刻、タイムゾーンが自動同期されているか確認してください。証明書のチェックを無効にして無理に接続すると、設定やセキュリティ上の問題が隠れてしまいます。

接続が復旧したら、ステータス表示が変わったかだけでなく、先ほど開けなかったサイトも確認してください。クライアントが接続済みでもサイトを開けない場合は、最初からアカウント確認を繰り返さず、次の項目に進みます。ルートの違いを先に確認したい場合はルート一覧を、初回設定をやり直す場合はクイックスタートをご覧ください。設定手順とトラブル診断を分けると、原因を追いやすくなります。

接続中の表示だけでは、サイトにアクセスできるとは限らない

クライアントの「接続済み」は、多くの場合、ネットワークコンポーネントが起動した、または接続が確立したことを示します。すべてのアプリがプロキシ経由になることや、接続先のサイトが現在の出口を受け入れることを保証するものではありません。まず、すべてのサイトが開けないのか、特定のサイトだけなのか、ブラウザーだけでなくデスクトップアプリでも失敗するのかを比較します。エラーをDNS名前解決の失敗、接続タイムアウト、証明書の警告、サイト側の拒否に分けると、次に確認する箇所を判断しやすくなります。

まず同じブラウザーで、通常なら直接開けるサイトを表示し、次に国際ルート経由で利用するサイトを開きます。クライアントを有効にした後、基本的なサイトにもアクセスできない場合は、システムプロキシ、通信モード、DNSを優先して確認してください。特定のサイトだけ失敗する場合は、エラー画面を記録し、同じルートでほかのサイトが開くか確認します。ひとつのサイトが開かないからといって、すべてのルートが使えないとは限りません。サイトのメンテナンス、アカウント権限、地域ごとのルールでも似た状態が起こります。

システムプロキシと接続モードを確認する

クライアントでシステムプロキシが有効になっているか、プロキシの接続先が現在起動中のクライアントを指しているか確認します。経験だけを頼りにローカルポートを手入力せず、クライアントに表示されている値を使ってください。システムプロキシに従うアプリもあれば、独自の接続方法を使うアプリもあります。そのため、ブラウザーでアクセスできても、すべてのソフトが同じ経路を使っているとは限りません。クライアントに仮想ネットワークアダプターのモードがある場合は、権限と影響範囲を理解したうえで比較します。最初からすべての通信制御機能を同時に有効にしないでください。

ルールモードでは、ドメインによって直接接続に振り分けられることがあります。一時的にグローバルモードに切り替えると、ルールの不足かどうかを判断しやすくなります。グローバルモードでは復旧し、ルールモードでは失敗する場合は、出口を何度も切り替えるのではなく、対象ドメインや関連リソースのドメインに適用されるルールを確認してください。テスト後は普段のモードに戻し、すべてのローカルサービスがプロキシ経由にならないようにします。グローバルモードは原因特定のための手段であり、アプリごとのルール確認に代わるものではありません。

エラーの種類に応じて次の確認項目を選ぶ

ドメインを名前解決できない場合は、DNSの項目でリゾルバーとクライアントのログを確認します。接続がタイムアウトする場合は、別のルートやネットワークで比較してください。証明書エラーが出た場合は、システム時刻、対象ドメイン、ネットワークへのログイン画面を確認します。正体不明のページにアカウント情報を入力したり、警告を消すために出所不明のルート証明書をインストールしたりしないでください。サイトから地域やアカウントに関する制限が明示された場合は、接続だけでは解決できないため、対象サービスのルールに従ってください。

ページのタイトルは表示されるのに画像が読み込まれない、またはログインできない場合、メインページとリソースのリクエストが異なる経路を通っている可能性があります。ブラウザーの開発者ツールでネットワークタブを確認すると、失敗したリクエストのドメインやエラーの種類を把握できます。記録するのは必要なドメインと状態だけにし、リクエストヘッダー全体、セッション情報、認証パラメーター付きのURLは公開しないでください。サポートには「ページは開くが、ログイン用リソースがタイムアウトする」のように発生段階を伝えると、「サイトが使えない」とだけ伝えるより原因を特定しやすくなります。

まずリクエストがクライアントを経由しているかを確認し、その後で出口から対象サイトにアクセスできるかを調べます。システムプロキシ、仮想ネットワークアダプター、ルールモードはそれぞれ別の確認項目です。一度のテストでまとめて変更しないでください。

ブラウザー固有の設定による影響を確認する

ブラウザー拡張機能、独自プロキシ設定、安全なDNS、キャッシュがシステム設定と異なる結果を招くことがあります。一時的なブラウザーセッションを作り、ネットワーク関連とわかっている拡張機能を一時的に無効にして、同じサイトを再度開いてみてください。プライベートブラウズでも、すべての拡張機能やシステム設定が無効になるとは限らず、完全にクリーンな環境とは言えません。別のブラウザーで正常に開ける場合は、クライアントを再インストールする前にブラウザー固有の設定を比較してください。

復旧後は、サイトの表示、ログイン操作、実際に使うアプリをそれぞれ確認してください。「接続表示は正常なのに通信がルートを通らない」場合の詳しい確認方法は、出口IP・DNS・アプリ別の通信確認ガイドをご覧ください。サポートへ連絡する際は、失敗したドメイン、エラー全文、プロキシモード、モード切替後の違いを伝えれば十分です。個人の閲覧履歴やアカウント画面全体を送る必要はありません。

まず、どの段階が遅いかを確認する

ページの初回表示、動画のバッファリング、ファイルのダウンロード、操作への応答の遅れは、それぞれ異なる原因が考えられます。初回表示にはDNSの名前解決と接続確立が関係し、継続的なダウンロードには利用可能な帯域幅が、オンライン操作には遅延、ジッター、パケットロスが影響します。「文字は表示されるが、画像の読み込みが続く」のように実際の状況を記録し、「速度が悪い」だけで済ませないでください。クライアントのリストに表示される単独の測定結果は、アプリの通信全体を示すものではありません。

ローカルネットワークでダウンロード、クラウド同期、システム更新、ほかの端末の通信が発生していないか確認します。Wi-Fiの電波強度、干渉、アクセスポイントの負荷も影響します。ルートを変えず、心当たりのある大容量通信を一時停止して、同じ操作を試してください。可能であれば別の接続方法でも比較します。通常のネットワークが安定していると確認できてから、ボトルネックが国際回線、出口、接続先サービスのどこにあるかを調べます。ローカルの混雑をサブスクリプションの問題と混同しないようにしましょう。

比較条件をそろえてルートを確認する

同じ接続先、同じアプリ、なるべく近い利用条件でルートを比較してください。片方は動画、もう片方はダウンロードという測り方では比較になりません。地域間の距離はあくまで目安です。地理的に近くても、通信事業者の経路が短いとは限りません。IEPL専線、中継、直結では経路の構成が異なり、実際の速度はローカルの接続環境、個別のルート、接続先サービスにも左右されます。まず利用したい地域内でルートの種類を切り替え、その後に出口の地域を変えるか検討してください。

速度測定を大量に繰り返したり、長い動画を何度も更新して変化を確認したりしないでください。データ容量を消費するうえ、キャッシュやサービス側の画質自動調整の影響も混ざります。普段の操作を試し、利用した時間帯、選んだルート、失敗した段階、実際の症状を記録する方法がおすすめです。速度測定を参考にする場合は測定先と環境を明記し、一度の結果をすべてのアプリの速度保証として扱わないでください。

夜間の遅延は発生時間を記録する

日中は正常で夜間に遅くなる場合は、同じ時間帯に通常のネットワークも遅くなっていないか確認します。共有ネットワーク、家庭内の複数端末の利用、地域間回線の混雑が重なっている可能性があります。アプリと接続先はそのままにして異なる種類のルートを比較し、どの組み合わせで改善するか、どれが失敗するかを記録してください。クライアントを何度も再起動しても、時間帯による混雑は解決しないことが多く、原因を判断するための接続状態まで失われるおそれがあります。

ルートを切り替えた直後のページ表示だけを見て判断しないでください。動画サービスが以前の接続やキャッシュを使い続けたり、ファイルのダウンロードが先に確立したセッションを維持したりすることがあります。切り替え後はテストをやり直し、実際の動作を観察してください。ライブ配信だけが止まり、オンデマンド動画は正常な場合は、ライブ配信のバッファーが小さいことや、試合配信の接続先に負荷が集中していることも考えられます。オンデマンド動画が見られるからといって、ライブ配信も同じようにスムーズとは限りません。

データ容量と速度の問題を混同しない

月額サブスクリプションは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。データ容量は利用できる量を示すもので、速度の指標ではありません。容量が大きいからといって、速度が必ず速くなるとは限りません。データ使用量や料金体系を比較する場合は、プラン料金をご確認ください。アカウントに容量超過と表示されている場合は、DNS設定や地域を何度も変更するのではなく、まず使用量の問題に対処してください。

速度の問題を問い合わせる際は、発生時間帯、接続方法、ルート名、対象アプリ、ルートやネットワークを変更した後の違いをお知らせください。状況がわからない速度測定のスクリーンショットだけでは、原因を特定しにくくなります。スポーツのライブ配信に適したルートの選び方は低遅延と試合開催時のルート選びを、出張先のネットワークを確認する場合はホテルのネットワークと海外出張時の利用をご覧ください。

まず、どの部分が切断されるか確認する

切断には、クライアントのステータスがオフになる、接続中と表示されたままアプリがタイムアウトする、長時間の通信だけ中断するといったケースがあります。切断時にクライアントが起動していたか、システムのネットワークが切り替わったか、ほかのアプリも同時に通信できなくなったかを記録してください。画面上は接続中なのにリクエストが失敗する場合は、ウェブアクセスとDNSの項目を確認します。クライアントがシステムによって終了される場合は、サブスクリプションを変更する前にバックグラウンド動作と電源管理を確認してください。

画面ロック、アプリの切り替え、スリープ、Wi-Fiからモバイルネットワークへの切り替え、アクセスポイントから離れたときに切断が起きるか確認します。ネットワークが切り替わると既存の通信経路が変わり、進行中のセッションがそのまま維持されるとは限りません。「切り替え後、一時的に再接続して復旧する」と「切り替え後、再接続できない」を区別してください。原因を調べるうえで意味が異なるため、問い合わせ時にも別々に説明します。

モバイル端末ではシステムのバックグラウンド制限を確認する

Android端末では、システムのアプリ設定でクライアントのバッテリー使用量とバックグラウンド動作の権限を確認できます。メニュー名は端末によって異なるため、実際のシステム画面を確認してください。厳しい省電力設定やバックグラウンド通信の制限が適用されている場合は、利用状況に応じて調整し、画面ロック時の動作を確認します。動作維持のためにすべてのアプリの電源管理を無効にしたり、出所不明のバックグラウンド強化ツールをインストールしたりしないでください。調整する対象が使用中のクライアントであることを確かめてください。

iOSでは、システムのVPN構成が現在のクライアントを参照しているか、ほかのツールが残した接続構成がないか確認します。システム上のネットワーク拡張機能は通常のアプリとは異なる方法で動作するため、バックグラウンドに切り替えただけで接続が終了したと判断しないでください。画面ロック後に特定のアプリだけ反応しなくなった場合は、アプリを開き直して接続状態を確認します。システムのVPN状態も同時にオフになる場合は、そのときのネットワーク切り替えやシステムの警告を記録してください。

デスクトップではスリープとネットワークコンポーネントの競合を確認する

Windows、macOS、Linuxでは、スリープから復帰した後にネットワークインターフェース、ルート、名前解決の状態が再構築される場合があります。まずシステムのネットワーク接続が復旧したことを確認し、クライアントを再接続してください。復帰のたびに失敗し、手動で再接続すると正常になる場合は、復帰処理に関係する問題が考えられます。何度も再インストールするより、復帰前後の状態とエラーを保存するほうが役立ちます。システムプロキシが終了済みのローカルプロセスを参照していないかも確認してください。

複数のVPN、プロキシ、仮想ネットワークアダプター、企業向けセキュリティコンポーネントが同時に動作すると、ルートやネットワーク制御を取り合うことがあります。問題の確認時は、不要なツールを正常に終了し、必要なネットワークコンポーネントだけを残して再現を試みます。管理対象端末では組織が必要とするソフトを勝手に無効にせず、管理者に相談してください。特定のツールを停止して復旧しても、互換性を示す手がかりにすぎません。よくわからないシステムサービスやドライバーを削除しないでください。

「バックグラウンド動作を許可」は端末側の条件に関する設定であり、ルートが切断されないことを保証するものではありません。画面ロック、スリープ、ネットワークの切り替え、接続先サービスのタイムアウトをそれぞれ確認してください。

再現条件に応じて対処方法を決める

特定のルートだけ頻繁に切断する場合は、端末とネットワークを変えず、別のルートで同じ操作を試してください。すべてのルートが同じネットワークで切断する場合は、別のネットワークで比較します。特定のアプリだけ切断し、ブラウザーやほかの操作が正常な場合は、アプリごとの通信ルール、セッションタイムアウト、接続先サービスの状態を確認してください。一度に変更する要素をひとつに絞り、偶然の復旧を設定変更の効果と誤認しないようにします。

MTU、接続タイムアウト、低レベルの通信パラメーターを根拠なく変更しないでください。設定値はクライアントやネットワークの条件に応じて判断する必要があり、安易に他の環境の値をコピーすると、正常に動いていたアプリに影響することがあります。サポートから特定の値を試すよう案内された場合は、現在の値を保存し、テストの目的を確認してから変更します。テスト後は設定を維持するか元に戻すか判断してください。一般の利用者は、権限、バックグラウンド制限、ネットワーク切り替え、代替ルートを確認してから、状況のわかる診断結果を添えて問い合わせるとよいでしょう。

同じ操作で切断を再現できる、画面ロック後にクライアントが終了したままになる、異なるネットワークでも同じ切断エラーが起きる、復旧後もシステムのネットワークが正常に戻らない場合は、問い合わせを検討してください。きっかけとなった操作、アプリが前面かバックグラウンドか、システムの警告、復旧方法を添えます。関係するエラー部分だけを共有し、個人ファイルをまとめてアップロードしないでください。利用可能な代替ルートが見つかった場合は、日常利用を続けながら原因を調べられます。

取得、更新、接続を切り分ける

サブスクリプションリンクを使うと、クライアントがアカウントに対応した設定を取得できます。サブスクリプションの取得、設定のダウンロード、ルートへの接続はそれぞれ別の操作です。更新に失敗しても、保存済みのルートがすぐに使えなくなるとは限りません。古い設定で接続できても、ルートの変更は反映されない場合があります。逆に、更新に成功しても、現在のネットワークで各ルートが使えることを示すものではありません。どの操作で失敗したかを記録し、サブスクリプションのエラーとルートの接続エラーを混同しないようにしてください。

ユーザーパネルでアカウントとプランの状態を確認し、パネルに表示された方法でサブスクリプションを取得します。メールアドレスは不要で、ユーザー名とパスワードだけで登録できます。既にアカウントがある場合は同じアカウントでログインしてください。設定エラーを解決するために新しいアカウントを何度も作成する必要はありません。サブスクリプションはアカウントへのアクセス情報です。公開の掲示板に貼ったり、見知らぬ変換サイトに入力したりしないでください。診断用のスクリーンショットでは、リンクに含まれる認証パラメーターや個人のセッション情報を隠してください。

エラーメッセージからダウンロードの成否を確認する

ネットワークのタイムアウトやサブスクリプションのドメインを名前解決できないというエラーが出た場合は、まずユーザーパネルにアクセスできるか確認し、接続を切った場合と、現在使える接続を利用した場合の更新結果を比較してください。環境によっては、クライアントの更新処理がブラウザーと異なるネットワーク設定を使います。パネルを開けても更新できない場合、ブラウザーの通信経路が使えることしかわかりません。クライアントの更新リクエストが誤ったローカルプロキシや無効になったルートを経由していないか確認してください。

設定形式に対応していない、解析に失敗した、必須項目が不足しているというエラーが表示された場合は、読み込み方法とクライアントが対応する形式を確認します。通常のウェブページのURLをサブスクリプションリンクとして使ったり、リンクを引用符、改行、補足説明付きでコピーしたりしないでください。まずパネルに表示された対象クライアント用の読み込み方法を使います。手動でコピーする場合は先頭と末尾まで含まれていることを確認してください。ただし、正しくコピーできたことを証明するために、公開の質問ページへリンク全体を貼り付けないでください。

古い設定、空のリスト、重複読み込みを確認する

更新が完了したのにルートが表示されない場合は、同名の古い設定ではなく、更新した設定が現在有効になっているか確認します。クライアントに複数の設定が保存されていると、読み込み後も古い設定グループが選択されたままの場合があります。設定一覧で現在の項目を確認し、ルート一覧が折りたたまれていないかも確認してください。一部のルートだけが表示される場合は、フィルターやお気に入り表示が有効になっていないか確認します。現在の設定を確かめずに履歴をすべて削除すると、問題が起きたときに戻す手段を失うおそれがあります。

同じアカウントで別の端末なら更新できるのに、この端末では何度試しても失敗する場合は、読み込み方法、クライアントの設定、端末のネットワークを比較します。古い設定は残し、テスト用とわかる名前で新しい設定を作って読み込みます。成功を確認してから重複項目を整理してください。すべての端末で同じアカウントまたはサブスクリプションのエラーが出る場合は、各端末を再インストールするのではなく、パネルの状態を確認してサポートに問い合わせます。更新を繰り返しても、アカウント側の問題が自動で直るわけではありません。

https://example.com/sub?token=YOUR_TOKEN

上記のURLはサブスクリプションリンクの形式を説明するための例であり、YuanVPNの実際のリンクではありません。また、読み込んで使用することはできません。実際の操作ではユーザーパネルからリンクを取得してください。リンクに含まれる認証情報はアクセスに使用されます。問い合わせの件名、公開スクリーンショット、共有ドキュメントに記載しないでください。サポートがアカウントを確認するために必要な情報は、チケット内の案内に従って提供してください。アカウントのパスワードは不要です。サブスクリプション全体を添付して送らないでください。

アカウントのデータ容量とリンクの安全性

更新エラーがデータ容量の超過やプランの状態に関係している場合は、プランページで適用条件を確認してください。月額サブスクリプションのデータ容量は契約開始日を基準に毎月リセットされ、途中でアップグレードした場合の差額は残り日数に応じて換算されます。データパックは使い切るまで有効で、期限切れになりません。これらのルールは端末のキャッシュを削除しても変わりません。更新に失敗しただけで、プランのアップグレードが必要とは限りません。次の対応は、パネルに明示された状態をもとに判断してください。

サブスクリプションが漏えいした疑いがある場合は、パネルで利用できるセキュリティ機能を使って対処してください。該当する項目が見つからない場合は問い合わせます。ログインパスワードを変更すれば古いサブスクリプションが必ず無効になると決めつけないでください。対処後、影響を受けた端末に設定を読み込み直し、古い設定が有効なままになっていないか確認します。サブスクリプションの仕組みや読み込みの順序は、サブスクリプションリンクの取得・読み込み・更新ガイドをご覧ください。この項目では、問題が起きた段階の切り分け方を説明します。

ブラウザーが正常でも、アプリの通信経路が同じとは限らない

デスクトップアプリ、ブラウザー、バックグラウンドサービスでは、異なるネットワーク方式が使われることがあります。システムプロキシに従うアプリ、独自のプロキシ設定を使うアプリ、クライアントによる広範なネットワーク制御を必要とするアプリがあります。そのため、「ブラウザーでは開けるのにアプリは使えない」場合、まず通信経路の違いを確認します。すぐにルートが使えないと判断する必要はありません。同じ接続先をブラウザーで開いた結果を確認し、アプリがログイン、リソースの読み込み、メッセージ送信、継続接続のどの段階で止まるかを記録してください。

アプリ独自のプロキシ設定を確認します。以前のローカルアドレス、ポート、自動設定URLが残っていると、システム設定より優先される場合があります。複数の場所にプロキシを設定して、システムが適切な経路を選ぶことを期待しないでください。まずアプリがどの設定を参照するかを確認し、クライアントに表示される情報と照らし合わせます。設定を変更した後、バックグラウンド常駐プロセスを含めてアプリを完全に終了し、再起動しなければ新しい接続が確立されないことがあります。ウィンドウを閉じるだけでは設定が反映されない場合があります。

モードを比較してルールの不足を探す

クライアントが該当機能に対応している場合は、ルールモードとグローバルモードを一時的に比較します。ルールモードでは失敗し、グローバルモードでは正常な場合、対象のリクエストに適切でない経路が割り当てられている可能性があります。クライアントの接続記録で、失敗時のドメイン、適用されたルール、選択されたポリシーを確認してください。アプリのメインサイトだけにルールを追加しないでください。ログイン、静的リソース、添付ファイル、リアルタイム接続に異なるドメインが使われることがあるため、実際のリクエストに応じて確認します。

グローバルモードでもアプリを通信制御できず、ブラウザーは正常な場合は、アプリがシステムプロキシを無視している可能性を確認してください。クライアントが仮想ネットワークアダプターのモードに対応している場合は、権限の説明を読んだうえで比較に利用します。有効にした後は、システムの許可とネットワークコンポーネントが正常に動作しているか確認してください。チェックを入れただけで通信制御が成功したとは限りません。影響範囲を理解せずにシステムのルーティングテーブルを変更せず、リクエストの記録から通信がクライアントに届いているかを確認します。

AIツールやメディアアプリで起こる特有の症状

AIツールでは、ウェブのログイン、APIリクエスト、長時間接続をそれぞれ別のプロセスが処理することがあります。アカウントページには入れるのにタスクを送信できない場合は、APIのドメインと実際のプロセスの通信経路を個別に確認してください。Cursorなどの開発ツールでは、拡張機能のプロセスやリモート環境からリクエストが送信される場合があり、ローカルブラウザーのプロキシ設定が適用されるとは限りません。まずリクエストがローカル端末、コンテナ、リモートホストのどこから送信されているかを確認し、ローカルのクライアントがどの区間に影響できるか判断します。

動画配信アプリでは、地域、セッション、リソースのURLがキャッシュされることがあります。ルートを変更したのに以前の地域が表示されても、必ずしも切り替えが失敗したとは限りません。まずアプリのセッションを再確立し、接続先サービスのルールに沿って確認してください。ネットワークに接続できることを、コンテンツの利用権限の保証として説明しないでください。視聴できるコンテンツは、接続先のサービス、アカウント、地域のルールにも左右されます。AIの利用についてはAI高速化ガイドで、ルートの種類についてはルートの説明で確認できます。

普段使うルールに戻し、変更は必要最小限にする

原因がわかったら、必要なルール変更だけを残し、変更の目的を記録してください。広範囲に適用されるルールを増やすと、ローカルサービスや正常だったアプリまで適切でない経路に振り分けられ、次回のトラブルシューティングも難しくなります。新しいルールで改善しない場合は、次のテストの前に元の値へ戻してください。一時的なテスト設定を記録せずに普段の設定へ混ぜると、後でサブスクリプションを更新した際、サービスの設定とローカル設定のどちらが原因か判断しにくくなります。

アプリの問題を問い合わせる際は、アプリ名、失敗した操作、使用したモード、そのリクエストがクライアントの記録に表示されたかを伝えてください。リクエストが記録にまったくない場合は通信制御の対象範囲を、クライアントに届いているのに接続先から拒否される場合は出口、接続先のルール、アカウント状態を重点的に確認します。スクリーンショットでは文書、会話、認証情報を隠してください。こうした切り分けにより、サポート担当者が「ウェブサイトは開けるか」という質問を繰り返さず、該当する段階から調査できます。

まず、本当に名前解決の問題か確認する

DNSはドメイン名を接続先のアドレスに変換します。ブラウザーにサーバーが見つからないと表示される、またはクライアントのログに名前解決の失敗が記録されている場合は、DNSを優先して確認します。接続タイムアウト、アカウントによる拒否、証明書エラーがDNSに起因するとは限りません。失敗したドメインとエラー全文を記録し、ほかのドメインでも同じ問題が起きるか比較してください。すべてのドメインを解決できない場合はローカルの名前解決経路を調べます。特定のドメインだけ失敗する場合は、接続先の状態と通信ルールも確認してください。

特定のアドレスを開けることだけを根拠に、DNSが正常だと判断しないでください。また、サイトのドメインをIPアドレスに置き換えてアクセスしないでください。現在のウェブサイトはドメイン名、証明書、仮想ホストの情報を使っているため、アドレスへ直接アクセスするとまったく異なる結果になる場合があります。システムの名前解決ツールで対象ドメインに応答があるか確認し、ブラウザーやクライアントの実際のリクエスト結果と照らし合わせてください。コマンドによる確認でわかるのは、そのコマンドが使う名前解決経路の結果だけです。すべてのアプリの状態を示すものではありません。

システムのツールで結果をそのまま記録する

Windowsではターミナルでnslookupを使用できます。macOSやLinuxでは、標準のnslookupを使うか、digが利用可能な環境ではdigを使用します。以下は公開されているテスト用ドメインの例です。実際の調査では失敗するドメインに置き換えてください。タイムアウトするか、アドレスが返るか、表示されたリゾルバーが現在の設定と一致するかを確認します。ツールがインストールされていない場合は、トラブルシューティングのために見知らぬサイトからダウンロードせず、クライアントに備わっている診断情報を確認してください。

nslookup example.com

dig example.com

curl -I https://example.com

これらのコマンドは、上から順にすべて実行して修復する手順ではありません。前半の問い合わせではドメインの名前解決を確認し、curlでは現在のコマンド環境からのHTTPSリクエスト結果を確認します。ターミナルがプロキシを使うかどうかは環境設定にも左右されます。アドレスが返ってもcurlが失敗するからといって、DNSを完全に原因から除外することはできません。ブラウザーが独自の安全なDNSを使う場合や、クライアントが独自の名前解決方式を使う場合もあるため、実際の経路を分けて確認してください。

システム、ブラウザー、クライアントの名前解決元を整理する

システムのネットワーク設定でリゾルバーを手動指定していないか、ブラウザーで独自の安全なDNSが有効になっていないか、クライアントでDNSの制御が有効になっていないか確認します。複数の設定が共存していること自体が問題とは限りませんが、「システムのDNSを変更しても変化がない」という状況につながりやすくなります。まず現在の設定がどこから適用されているか記録し、古い設定や使わなくなった手動指定を元に戻します。複数のガイドからリゾルバーやルールを寄せ集め、対象リクエストを実際に処理する設定がどれかを把握しないまま変更しないでください。

クライアントによっては仮想アドレスやFake-IPに似た名前解決方式を使うため、アプリに見えるアドレスが公開DNSの問い合わせ結果と異なることがあります。それだけで異常とは限りません。重要なのは、そのリクエストをクライアントが正しく制御して転送できるかどうかです。アプリがクライアントを通らない場合や、ローカルネットワークの一部サービスがその方式に適さない場合は、クライアントの説明に沿って除外ルールを確認してください。見慣れないアドレスが表示されたという理由だけで設定全体を削除したり、問題を隠すためにシステムのhostsファイルを変更したりしないでください。

まず「どのコンポーネントが名前解決しているか」を確認し、それからどの層のキャッシュを消すか判断します。キャッシュを削除しても、無効なリゾルバー、誤った通信ルール、接続先サービス自体の問題は解決しません。

キャッシュ、ネットワークの切り替え、ローカルネットワークの範囲

DNS設定やルートを変更した後は、古いキャッシュや既存の接続がしばらく結果に影響することがあります。影響を受けているアプリを完全に終了してから開き直し、必要に応じてOSの公式手順に沿ってキャッシュを更新してください。操作前に新しい設定が適用されていることを確認します。設定が有効になっていなければ、キャッシュを消しても同じエラーが再び表示されます。スリープからの復帰後やネットワーク切り替え後に問題が起きた場合は、システムが現在のネットワーク設定を正しく取得したことを確認してから、クライアントを再接続します。

ローカルネットワークの端末、組織内ドメイン、公開サイトでは、それぞれ異なる名前解決経路が必要な場合があります。DNSの制御範囲を広げた後にプリンター、ファイル共有、内部サービスで問題が起きた場合は、ローカルドメインを直接接続し、ローカルで名前解決する必要があるか確認してください。管理対象のネットワーク設定は管理者に確認し、組織内で必要な設定を公開リゾルバーで上書きしないでください。目的は利用環境に適した通信経路を復元することであり、すべてのドメインに同じ名前解決元を使うことではありません。

同じドメインが異なるネットワークやルートでも一貫して名前解決に失敗する場合は、個人情報を伏せた問い合わせ結果、名前解決元の設定、クライアントのエラー部分を添えてサポートに連絡してください。社内ドメインや内部リゾルバーのアドレスは組織の情報にあたる場合があるため、許可なく公開しないでください。名前解決の経路と実際の出口を合わせて確認するには、接続が実際に機能しているかを確認するガイドもご覧ください。一度の問い合わせ結果だけで、プライバシーや接続全体を判断しないようにしましょう。

端末数の上限と表示されたら、まず表示元を確認する

YuanVPNは同時接続台数に制限がありません。「端末数の上限」といったメッセージが表示された場合は、YuanVPNのクライアントやユーザーパネルによるものか、利用中の第三者サービスによるものかを確認します。第三者サービスには独自のセッションや端末に関するルールがあるため、本サービスの端末数の条件を当てはめることはできません。メッセージ全文と表示場所を記録してください。途中で切れた文言だけを根拠に、サブスクリプションの端末数を増やす必要があると判断したり、同じプランを繰り返し購入したりしないでください。

本サービスに関係する画面に表示されている場合は、想定したアカウントでログインしているか、現在の設定がそのアカウントから取得されたか、古いクライアントや過去の設定が混在していないか確認してください。同時接続台数に制限がなくても、端末側の権限、ネットワーク、設定が競合することはあります。また、接続先サイトに同時アクセスの独自制限がないことを意味するものでもありません。正しいアカウントでも表示が続く場合は、画面と発生時の操作を記録して問い合わせてください。異常を説明するために、根拠のない端末数の制限を想定しないでください。

再現できる記録として問い合わせ内容をまとめる

ユーザーパネルから問い合わせを送信するか、先にサポートページで問い合わせ窓口を確認してください。件名には「画面ロック後に接続が切れる」「サブスクリプション更新時に名前解決エラーが出る」のように、症状と利用状況を記載します。本文には発生時刻、利用プラットフォーム、選択したルート、実行した操作、実際の結果をまとめてください。それまで正常に使えていたか、最近変更したこと、ほかの端末でも同じ症状が起きるかも伝えると、漠然とした説明より原因を特定しやすくなります。

システムとクライアントの情報は設定画面またはバージョン情報から確認し、記憶に頼らず実際の内容を伝えてください。ルートの情報には名前、地域、種類を記載します。ネットワークについては、自宅のWi-Fi、公共のネットワーク、モバイルネットワークなどの利用状況を説明すれば十分で、個人のアドレスを自発的に伝える必要はありません。接続先の問題は、具体的なドメインまたはアプリ名、失敗した段階、エラー全文を記載してください。発生時間帯は比較に役立ちますが、一度の異常を長期的な全面停止として説明しないでください。

問い合わせの記入例：何が起きたか、どのような環境で起きたか、どのように再現するか、何を試したか、各試行でどう変化したか。サブスクリプション全体、パスワード、セッション認証情報を添付する必要はありません。

ログとスクリーンショットは必要な範囲だけ共有する

クライアントの診断ログには、アクセスしたドメイン、端末のパス、ローカルネットワークの情報、認証パラメーターが含まれる場合があります。問題が起きた時刻付近のエラー部分を探し、機密情報を隠してからチケットで送信してください。デスクトップ全体、個人文書、閲覧履歴全体をそのまま添付しないでください。共有できるか判断しにくい項目がある場合は、先にエラー内容だけを説明し、必要な情報をサポートに確認してください。スクリーンショットにサブスクリプションのQRコードが写っている場合も、アクセス情報として扱い、隠してください。

「ログを記録しない」はYuanVPNのサービスにおけるプライバシー方針を示す表現であり、端末上でトラブルシューティング用の動作情報が生成されないという意味ではありません。サービスの方針、クライアント上のローカル診断情報、ユーザーが問い合わせ時に送る資料は、それぞれ分けて考えてください。データの取り扱い範囲についてはプライバシーポリシーをご確認ください。診断では現在の問題に関係する情報だけを集め、故障の証明のために必要以上の内容を送らないでください。サポートとのやり取りを公開することも、トラブルシューティングの手順として推奨されません。

復旧後に動作を確認し、一時的な変更を元に戻す

問題が解決したら、以前失敗した操作をもう一度試し、もともと正常だったローカルサービスも確認します。一時的なグローバルモード、テスト用ルール、手動プロキシの設定を普段使いに適した状態へ戻し、終了済みのクライアントを参照するプロキシ設定がシステムに残っていないか確認してください。テスト用に重複設定を作成した場合は、現在の設定が使えることを確かめてから不要な項目を整理します。最後に有効だった変更を簡潔に記録しておくと、似た症状が起きたときにやみくもに試し直さず、比較に役立てられます。

データ使用量に合ったプランを選べていないとわかった場合は、ルートの問題と混同せず、プラン料金で月額サブスクリプションとデータパックを比較してください。支払い方法はAlipay / WeChat Pay / USDTです。本サービスでは14日間の理由を問わない返金を受け付けています。適用条件は利用規約をご覧ください。返金や請求に関する質問はチケットからお問い合わせください。技術的なトラブルシューティングによって、アカウントの請求方法、データ容量のリセットルール、返金条件が変更されることはありません。

トラブルシューティングの完了は、ステータス表示が緑色になったときではありません。元の操作が復旧し、繰り返し確認でき、ほかのアプリに影響する一時設定が残っていないことが基準です。解決しない場合は、すでに確認した項目をサポートに伝えて続きの調査を依頼してください。すべての手順を最初からやり直す必要はありません。初回のインストールと読み込みはクイックスタートを、よくある質問はヘルプセンターをご覧ください。このページは症状から確認できるトラブルシューティングガイドです。