まずはプラン、サブスクリプション、クライアントの違いを確認
初心者が最初につまずきやすいのは、回線そのものではなく、プラン、サブスクリプションURL、クライアントを同じものとして扱ってしまうことです。プランは利用できるサービス範囲と通信量の条件を決めます。サブスクリプションURLは、利用可能な回線と関連パラメータをクライアントに渡します。クライアントはWindows、macOS、iOS、Android、Linux上で実際の接続を確立します。購入が完了しただけでは、サービスを設定できる状態になったことを意味し、端末が自動接続されるわけではありません。
操作を始める前に、アカウントで管理パネルへ正常にアクセスできることを確認し、ユーザー名とパスワードを安全に保存しておきましょう。MeeVPNはメールアドレスなしで登録できるため、アカウント情報は特に慎重に管理してください。パスワードやサブスクリプションURLを公開文書、公開コードリポジトリ、不特定多数が見られるチャットに貼り付けないでください。サブスクリプションURLからアカウントに紐づく回線設定を取得できる場合があるため、機密情報として扱う必要があります。
利用スタイルに合わせてプランを選ぶ
国際アクセスを継続的かつ定期的に利用するなら、月額プランのほうが期間単位で管理しやすいでしょう。たまに使うだけ、または利用間隔が不定期なら、時間の経過で失効しない通信量パックも選択肢になります。名称だけでなく、動画、ファイル同期、システム更新、クラウド開発などのバックグラウンド通信も考慮してください。クライアントに表示される通信量には、アプリの自動リクエストやバックグラウンド処理も含まれることがあり、ブラウザーの閲覧だけを示すものではありません。
プランを決めたら、全体の流れは次のとおりです。ユーザーパネルに入り、サブスクリプション情報を開き、URLをコピーします。現在のプラットフォームに合うクライアントをインストールし、サブスクリプションを読み込み、回線一覧を更新してノードを選択。接続を開始したら、最後に出口アドレスとDNSの解決結果を確認します。この順番で一つずつ確認すれば、問題がアカウント、サブスクリプション、クライアント、ネットワーク環境のどこにあるかをすばやく切り分けられます。
サブスクリプションURLを取得し、有効性を確認する
サブスクリプションURLは、通常のウェブページのブックマーク用アドレスではありません。クライアントがURLへアクセスすると、エンコードまたは構造化された回線設定を読み込みます。そこにはサーバーアドレス、ポート、プロトコル、認証情報などが含まれる場合があります。クライアントによって対応するサブスクリプション形式は異なるため、パネルに複数の読み込み方法がある場合は、クライアント名や使用するコアに合うものを選び、任意のURLをコピーしないでください。
ユーザーパネルからサブスクリプションをコピーする
- ユーザーパネルにログインし、プランの状態が正常であることを確認します。
- サブスクリプションまたはクライアント設定のセクションを開き、現在のクライアントに合う読み込み項目を探します。
- コピー用ボタンでURL全体を取得します。ドラッグで選択すると、先頭や末尾の文字が抜けることがあります。
- クライアントに切り替え、「URLから読み込む」「サブスクリプションを追加」など、同様の意味の項目に貼り付けます。
- 保存後、手動で一度更新し、回線一覧が表示されるか確認します。
クライアントに形式エラーが表示されても、すぐに再インストールを繰り返さないでください。パネルに戻り、コピーしたものがサブスクリプションURLであり、パネルのページURL、ソフトウェアのダウンロードURL、単一ノードの説明ではないことを確認します。貼り付けた内容の前後に空白、改行、全角の句読点が入っていないかも確認してください。OSによってはクリップボードのURLがクリック可能なテキストとして認識されますが、クライアントが必要とするのは元の文字列です。
サブスクリプションの読み込みに成功すると、通常はクライアント内に設定グループが作成されます。このグループはリモートのサブスクリプションURLを保存し、更新時に回線情報を置き換えたり追加したりします。サブスクリプションから生成されたノードのパラメータを手動で変更すると、次回の更新で上書きされる可能性があります。独自の振り分けルールが必要な場合は、リモートノードを直接書き換えず、クライアントが保持できるローカルルールの領域に設定してください。
プラットフォームに合うクライアントを選ぶ
クライアントの見た目は異なりますが、基本的な役割は共通しています。サブスクリプションを読み込み、回線を選択し、プロキシまたはトンネルを確立し、どのリクエストを国際回線に通すかをルールに従って決めます。選ぶ際は機能の多さよりも、サブスクリプションで使われるプロトコルに対応しているか、OSに適合しているか、システムプロキシ、TUNモード、アプリごとの振り分けなど必要な機能を備えているかを重視してください。
| プラットフォーム | 一般的な接続方法 | 注意が必要な権限 | 確認しやすい項目 |
|---|---|---|---|
| Windows | システムプロキシまたはTUNモード | 仮想ネットワークアダプターとファイアウォールの警告 | プロキシの切り替え、バックグラウンド常駐、起動時の自動実行 |
| macOS | システムプロキシまたはネットワーク拡張 | ネットワーク拡張とシステム設定の許可 | メニューバーの状態、プロキシの残留、スリープ復帰 |
| iOS | システムVPN設定 | 初回の設定追加時に求められるシステム許可 | 設定状態、オンデマンド接続、ネットワーク切り替え |
| Android | ローカルVPNインターフェース | VPN接続とバックグラウンド実行の権限 | 省電力制限、アプリごとのプロキシ、ネットワーク切り替え |
| Linux | GUIクライアント、コマンドライン、サービスプロセス | TUNデバイス、ルーティング、サービス権限 | 環境変数、ルーティングテーブル、プロセスログ |
WindowsとmacOSのシステムプロキシは通常、システムプロキシ設定に従うアプリに主に影響します。一部のゲーム、コマンドラインツール、独自にネットワーク接続を確立するソフトウェアは、自動的にプロキシを経由しない場合があります。TUNモードは仮想ネットワークインターフェースを作成するため、対象範囲がより広くなる一方、企業VPN、セキュリティソフト、仮想マシンのネットワーク、既存のルーティングルールと競合しやすくなります。
iOSとAndroidのクライアントは通常、OSが提供するVPNインターフェースを使って通信を転送します。ステータスバーに接続済みと表示されても、ローカルトンネルが確立したことを示すだけで、遠端の回線が利用可能だとは限りません。Linuxでは、デスクトップセッションのプロキシ設定、ターミナルの環境変数、システムレベルのルーティングを区別することが重要です。ブラウザーではアクセスできるのにコマンドラインで失敗する場合、両者が同じプロキシ経路を使っていない可能性があります。
サブスクリプションを読み込み、回線を更新して接続を開始する
クライアントをインストールした直後は、すべての高度なオプションを有効にしないことをおすすめします。まずは標準ルールのまま、最小限の接続を一度確立してから、必要に応じて振り分けやDNSを調整してください。変更項目を絞ることで、問題が起きた際に原因を特定しやすくなります。
基本的な読み込み手順
- クライアントの設定、サブスクリプション、または設定ファイルのページを開きます。
- URLでサブスクリプションを追加する項目を選び、パネルからコピーしたアドレスを貼り付けます。
- サブスクリプションに識別しやすいローカル名を付けます。この名前は端末上での管理にのみ使用されます。
- 保存して更新を実行し、ノードグループの読み込みが完了するまで待ちます。
- 現在の用途に合う回線をノード一覧から選択します。
- システムプロキシ、またはクライアントが推奨する接続モードを有効にします。
- ブラウザーを開いてアクセスをテストし、その後ほかのよく使うアプリも確認します。
回線一覧は表示されるのに接続ボタンを押しても反応しない場合は、クライアントのステータスバーとログを確認します。よくある表示には、サブスクリプションが選択されていない、コアプロセスが起動していない、ポートが使用中、プロトコルに未対応、システムプロキシの書き込み失敗、TUNデバイスの作成失敗などがあります。ログのサーバーアドレス、鍵、サブスクリプション内容はそのまま公開しないでください。サポートへ伝える際は、エラーの種類と発生段階を残しつつ、機密情報を隠してください。
クライアントに「自動選択」「フェイルオーバー」「手動ノード」モードがある場合、初心者はまず手動ノードで確認するとよいでしょう。自動選択はクライアント独自の検出方法に依存します。検出先が応答しても、すべての対象サイトに適した回線とは限りません。手動で回線を選べば、問題が安定して再現するかを確認しやすくなります。基本接続が正常だと分かってから、自動選択で日常の切り替えを減らしてください。
プロトコル、直結、中継、IEPL専線を理解する
サブスクリプション一覧の名前には、地域、都市、回線種別、プロトコルが同時に含まれる場合があります。地域は出口の位置、回線種別はローカルネットワークから遠端ノードまでのおおまかな経路、プロトコルはクライアントとサーバーがデータをカプセル化・転送する方法を示します。これらは異なる層の要素なので、プロトコル名だけで回線の速度や安定性を判断することはできません。
代表的なプロトコルが適する環境
| プロトコル | 通信上の特徴 | クライアント選びのポイント |
|---|---|---|
| Shadowsocks | 比較的シンプルな構成で、暗号化プロキシを使って通信します | 暗号化方式とクライアントのコアに互換性があるか確認します |
| VMess | 対応するプロキシ環境でよく使われ、さまざまな転送方式と組み合わせられます | 転送層、TLS、経路パラメータがすべて揃っているか確認します |
| VLESS | 認証と転送設定が分離され、具体的な動作は組み合わせによって変わります | クライアントがサブスクリプションに指定された転送の組み合わせ全体に対応している必要があります |
| Trojan | 通常はTLSと組み合わせて通信を確立します | システム時刻、証明書の検証、ドメイン名前解決が正常である必要があります |
| Hysteria2 | QUICをベースに、変動やパケットロスのある環境向けに転送を最適化します | 現在のネットワークで必要なUDP通信が許可されているか確認します |
| TUIC | 同じくQUICをベースとし、UDP経路の品質に左右されます | 制限のあるネットワークでは、代替として別のプロトコルも用意します |
対応プロトコルは、サブスクリプションの内容とクライアントのコアを基準に判断してください。クライアントがサブスクリプションを認識できても、その中のすべてのノードを実行できるとは限りません。古いコアでは、新しいプロトコルや転送パラメータを含むノードをスキップしたり、接続時にエラーが発生したりする場合があります。その場合は、信頼できる提供元のクライアントを更新するか、パネルが推奨する互換クライアントを使い、サーバーパラメータを推測して手動入力しないでください。
直結、中継、IEPLの違い
直結回線は、現在利用している通信事業者の公開ネットワーク経由で遠端サーバーへ直接到達します。経路はローカル事業者、国際出口、インターネット上の混雑の影響を受けやすくなります。設定は簡単ですが、地域や接続ネットワークによって性能に大きな差が出る場合があります。
中継回線は、まず近い、または経路上の条件がよい入口へ接続し、その後、中継ネットワークを通じて目的地域へ送信します。中継の利点は公開ネットワーク上の経路を調整し、望ましくない国際経路を避けやすくすることです。ただし、入口の品質、転送経路、遠端出口を総合的に判断する必要があり、ノード名だけで決めることはできません。
IEPLは一般に、国際イーサネット専線に類する接続を指し、ネットワークノード間でより管理しやすい伝送経路を提供します。実際のサービスにはローカル接続、入口での転送、出口ノードなどが含まれる場合があるため、専線という表示だけで、端末から対象サイトまでの全区間が完全に独立しているとは限りません。現在のネットワークでの実際の接続状況、目的地域、アプリの種類を合わせて選び、回線名だけで結論を出さないようにしてください。
接続後に出口、DNS、実際のアプリを確認する
クライアントに「接続済み」と表示されることは、確認の出発点にすぎません。出口アドレス、ドメイン名前解決、ブラウザーのアクセス、対象アプリまで確認してください。普段見るページを一つ開くだけでは、ブラウザーキャッシュによって問題が一時的に見えないことがあります。出口アドレスだけを確認すると、DNSがローカルネットワークで解決され続けている問題を見落とす可能性もあります。
次の順番で基本確認を行う
- クライアントが接続状態を維持し、再接続や認証エラーを繰り返していないことを確認します。
- 出口アドレスの確認ページを開き、表示地域が選択した回線と一致するか確認します。
- DNSの解決結果がクライアントのDNSポリシーに沿っているか確認します。
- 国際アクセスが必要な実際のウェブサイトを開き、ログイン、画像、動画、APIリクエストをテストします。
- 続いてコマンドライン、開発ツール、同期ソフト、その他の日常的なアプリをテストします。
DNSリークとは通常、ネットワーク通信がプロキシやトンネルを経由している一方で、ドメイン検索だけが想定外のローカルリゾルバーによって処理される状態を指します。これにより、名前解決に失敗したり、現在の出口に適さないアドレスが返されたり、ローカルの名前解決経路が露出したりする可能性があります。まずクライアントがDNSを引き受けているか確認し、次に手動設定したDNSがシステムに残っていないか、ブラウザーで独自のセキュアDNSが有効になっていないか、振り分けルールがDNSリクエストを別の経路へ送っていないかを確認してください。
DNSの問題を単純に回線のせいにしないでください。ブラウザー内部のDNSキャッシュ、システムキャッシュ、古いプロキシプロセス、企業ネットワークのポリシーも結果に影響します。設定を変更したら古い接続を切断して再接続し、必要に応じて関連アプリを再起動して、新しいプロキシと名前解決ルールを確実に反映させます。
振り分けルールで回線を通す通信を決める
ルールモードでは、ドメイン、アドレス範囲、アプリ、ルールセットに基づいて、リクエストをプロキシ経由にするか直結にするかを決めます。グローバルモードはより多くの通信を選択した回線へ送るため、「対象リクエストが振り分けから漏れていないか」を調べるのに適しています。ルールモードはローカルサービスを直結させやすく、日常利用に向いていますが、ルールを最新に保ち、適用順を理解する必要があります。
ブラウザーではアクセスできるのに特定のアプリで失敗する場合は、そのアプリがシステムプロキシに従うか、UDPを独自に使うか、DNSを固定しているか、アプリごとのルールで直結に指定されていないかを確認します。反対に、アプリは正常でブラウザーだけ失敗する場合は、ブラウザー拡張、独自プロキシ設定、セキュアDNSを確認してください。複数のプロキシ拡張とシステムレベルのクライアントを同時に有効にすると、通信が二重にプロキシを経由したり、異なるルールが競合したりする可能性があります。
よくあるつまずきと推奨される確認順
サブスクリプションを読み込んでもノードが表示されない
まずパネルでサブスクリプションをコピーし直し、クライアントで正しい読み込み形式が選択されていることを確認して、手動で更新します。更新ログにネットワークリクエストの失敗が表示される場合は、ほかのプロキシツールを一時的に無効にして再試行します。形式を認識できないと表示される場合は、クライアントのコアがそのサブスクリプション形式に対応しているか確認してください。単一の共有URLをリモートサブスクリプション専用の入力欄に入れたり、サブスクリプションURLをローカル設定ファイルとして開いたりしないでください。
ノードは選択できるが、接続がタイムアウトし続ける
まず同じ地域の別の回線に切り替え、単一ノードの問題かローカルネットワークの問題かを切り分けます。その後、異なる接続ネットワークでも再テストしてください。Hysteria2またはTUICだけ接続できず、ほかのプロトコルは動作する場合、現在のネットワークでUDP経路が制限されている可能性があります。その場合は互換性のある別のプロトコルを選ぶのが近道です。すべての回線で失敗するなら、システム時刻、ファイアウォール、クライアントのコアプロセス、サブスクリプションの状態を確認します。
接続済みと表示されるが、ウェブページを開けない
まずルールモードを一時的にグローバルモードへ変更して比較します。グローバルモードで利用できるなら、問題は主に振り分けルールかDNSにあります。グローバルモードでも利用できない場合は、出口回線とクライアントログを確認してください。ブラウザーのプロキシ拡張を無効にし、別のクライアントが同じプロキシポートを使用していないことも確認できます。テスト後は、日常利用に適したルールモードへ戻してください。
一部のウェブサイトやアプリだけ失敗する
この種の問題では、すぐに再インストールする必要はありません。失敗する対象が特定のドメイン、UDP、長時間接続、独自DNSを使っていないか確認します。出口地域を切り替え、DNSキャッシュを更新し、ルールの適用状況を確認してください。一部のサービスは出口地域、アカウント地域、アクセス頻度に応じて表示内容を決めるため、回線に接続できても、すべてのサービスで同じ結果になるとは限りません。
サブスクリプションの更新時に失敗と表示される
サブスクリプションの更新には、クライアントがリモートのサブスクリプションURLへアクセスできる必要があります。URLが途中で切れていないか、アカウントの状態が正常か、システム時刻が正確か、クライアントが無効になった回線を経由して更新リクエストを送っていないか確認してください。一部のクライアントでは、更新時の直結またはプロキシ経路を指定できます。まず標準設定を使い、ログを見ながら調整してください。
接続後にローカルサイトが遅くなる
グローバルモードでは、ローカル向けのリクエストも遠端の出口を経由する場合があります。メンテナンスされたルールモードに切り替えてローカルサービスを直結させると、日常利用に適した状態になりやすくなります。ルールモードでも迂回が起きる場合は、ドメインが誤分類されていないか、DNSが異常なアドレスを返していないか、クライアントが最新ルールを実際に読み込んでいるかを確認します。
| 現象 | まず確認する項目 | 次の対応 |
|---|---|---|
| 回線一覧が表示されない | サブスクリプションURL、読み込み形式、更新ログ | コピーし直し、互換性のあるクライアントを使う |
| すべてのノードがタイムアウトする | ローカルネットワーク、システム時刻、ファイアウォール | ネットワークを変更し、コアのログを確認する |
| 一部のノードだけ失敗する | ノードの状態、プロトコル対応、UDP経路 | 同じ地域の別の回線に切り替える |
| ブラウザーは使えるが、アプリは失敗する | システムプロキシ、TUN、アプリごとのルール | アプリがプロキシを迂回していないか確認する |
| 出口は正しいが、名前解決に異常がある | クライアントDNS、ブラウザーのセキュアDNS | DNSポリシーを統一して再接続する |
正常接続後の日常的なメンテナンス
初回接続に成功した後は、すべてのパラメータを頻繁に調整する必要はありません。動作確認済みの基本設定を一つ残し、サブスクリプションとクライアントを定期的に更新しましょう。回線に変更があった場合は、まずサブスクリプションを更新し、その後同じ地域の回線から選び直します。クライアントのアップデート後に異常が発生したら、接続モード、権限、ローカルルールがリセットされていないか確認してください。
サブスクリプションURLは、利用する端末だけに保存してください。古い端末を使わなくなったら、クライアント内のサブスクリプションとキャッシュ設定を削除します。端末を紛失した場合、URLを公開してしまった場合、身に覚えのない利用がある場合は、パネルでサブスクリプションをリセットしてください。アカウントのパスワードもほかのサイトと分けて管理し、使い回しによる連鎖的なリスクを避けましょう。
サポートへ問題を伝える際は、プラットフォーム名、クライアント名、接続モード、選択した回線種別、エラーが発生した段階、機密情報を隠したログの一部を添えるとスムーズです。「接続できない」だけで済ませたり、完全なサブスクリプションURLを送ったりしないでください。「サブスクリプションを更新できない」「ノード接続がタイムアウトする」「出口は正常だがDNSに異常がある」「ブラウザーは使えるがコマンドラインは失敗する」のように具体的に伝えると、該当箇所から調査を始められます。
最後に、簡単なチェックリストを手元に残しておくと便利です。アカウントの状態、サブスクリプションの更新、クライアントコアの互換性、回線の選択、プロキシまたはTUNの有効化、出口地域、DNSの解決経路、よく使うアプリのテストを確認します。端末の変更やOSの再インストール時も同じ順番で進めれば、重要な手順を漏らしにくくなります。