回線一覧と選び方

グローバルノードと主要回線の分布

RZVPNは120か国以上・160以上の回線に対応しています。本ページでは主要地域の回線例を示し、IEPL専線、中継、直結の技術的な違いを解説します。選択時は名称の長さではなく、利用するサービスの地域、アプリの接続方式、現在のネットワーク環境を組み合わせて判断してください。

無料で始める料金プランを見る

120か国以上 160以上の回線接続台数無制限 14日間返金保証

ROUTE DIRECTORY RZVPN

IEPL TRANSIT DIRECT

Route inventory

地域別にサーバー回線を見る

以下の表は、主な出口地域と回線形態を示すもので、遅延、負荷、帯域幅の数値は掲載していません。ストリーミング欄の「対応」は、その地域をコンテンツアクセス時の候補出口として利用できることを示します。実際に利用できるコンテンツは、プラットフォームの地域ポリシー、アカウント状態、対象サービスの規約によって異なります。

APACアジア太平洋 NA北米 EU欧州 OTHERその他

国または地域	都市	回線タイプ	ストリーミング対応
アジア太平洋
日本	東京	IEPL専線	対応（対象地域に合わせて選択）
日本	大阪	中継	対応（対象地域に合わせて選択）
シンガポール	シンガポール	IEPL専線	対応（対象地域に合わせて選択）
中国・香港	香港	中継	対応（プラットフォームのポリシーによる）
韓国	ソウル	中継	対応（対象地域に合わせて選択）
オーストラリア	シドニー	直結	対応（プラットフォームのポリシーによる）
北米
米国	ロサンゼルス	IEPL専線	対応（対象地域に合わせて選択）
米国	サンノゼ	中継	対応（対象地域に合わせて選択）
米国	シアトル	直結	対応（プラットフォームのポリシーによる）
米国	ニューヨーク	中継	対応（対象地域に合わせて選択）
カナダ	バンクーバー	直結	対応（プラットフォームのポリシーによる）
カナダ	トロント	中継	対応（対象地域に合わせて選択）
欧州
英国	ロンドン	中継	対応（対象地域に合わせて選択）
フランス	パリ	直結	対応（プラットフォームのポリシーによる）
ドイツ	フランクフルト	中継	対応（対象地域に合わせて選択）
オランダ	アムステルダム	直結	対応（プラットフォームのポリシーによる）
スイス	チューリッヒ	直結	対応（プラットフォームのポリシーによる）
スウェーデン	ストックホルム	直結	対応（プラットフォームのポリシーによる）
その他の地域
インド	ムンバイ	中継	対応（対象地域に合わせて選択）
アラブ首長国連邦	ドバイ	中継	対応（対象地域に合わせて選択）
トルコ	イスタンブール	直結	対応（プラットフォームのポリシーによる）
ブラジル	サンパウロ	直結	対応（プラットフォームのポリシーによる）
南アフリカ	ヨハネスブルグ	直結	対応（プラットフォームのポリシーによる）
ニュージーランド	オークランド	直結	対応（プラットフォームのポリシーによる）

Transport methods

3種類の回線タイプの仕組み

IEPL専線、中継、直結は、それぞれ異なる経路上の課題に対応します。単純な優劣関係ではありません。距離が近く経路も適切なら直結で十分な場合があります。一方、地域をまたぐアクセスや現地出口の変動が大きい場合は、中継やIEPLのほうが経路を管理しやすくなります。

IEPL

IEPL専線

IEPL回線では、ユーザーの入口と海外出口の間にある主要な伝送区間を、専用に構成されたエンタープライズ向け経路に配置します。これにより、公共インターネットの経路変動が主要な国際区間へ与える影響を抑えます。クライアントは引き続き現地ネットワークから入口へ接続しますが、入口以降では、計画された伝送経路を通って対象地域の出口から海外のウェブサイトやアプリへアクセスします。

このタイプは、継続的な会議、リモートデスクトップ、コードリポジトリの同期、ストリーミング出力、長時間のデータ転送など、接続の継続性が重要な用途に適しています。一般的なインターネット経路よりコストが高いことが多いため、「専線」という名称だけで常用するのではなく、重要な作業向けの回線として使うのが適切です。

IEPLが必要かどうかは、短い揺らぎで作業が中断しやすいか、対象地域と出口が合っているかで判断します。日本のサービスには日本向け、北米のサービスには北米向けを優先し、比較してください。物理的に遠い専線を選ぶだけで、全体の経路が自動的に短くなるわけではありません。

TRANSIT

中継回線

中継回線は、近い場所または安定した経路の入口へ接続してから、入口経由で対象地域の出口へトラフィックを転送します。長距離の公共ネットワーク経路を、ユーザーから入口までと入口から出口までの2区間に分けて扱える点が特徴です。後半の経路を地域別に構成できるため、現地通信事業者の既定の国際経路だけに依存せずに済みます。

中継は、日常のウェブ閲覧、動画視聴、AIツールのウェブ版、一般的な業務に適しており、対応地域と経路コストのバランスにも優れています。対象サービスが遠い地域にある場合、同じ方向の直結より経路を安定させやすいことがあります。ただし入口と転送の工程が増えるため、最終的な結果は入口の品質と出口地域の選択に左右されます。

中継を選ぶときは、まず出口地域、次にアプリの動作を確認します。ページは開けるのにストリーミングが頻繁に待機する場合は、すぐ別の国へ変更せず、同じ地域の別の入口を比較してください。出口地域を固定して比べると、問題が伝送経路にあるのか、プラットフォームの地域ルールにあるのかを切り分けやすくなります。

DIRECT

直結回線

直結回線は、クライアントから公共インターネットを通じて対象地域の出口へ直接接続し、独立した転送入口を追加しません。経路がシンプルで設定上の負担も小さいため、利用場所から対象地域まで適切な経路がある場合、ウェブ閲覧、メッセージ同期、情報検索、短時間の接続などに利用できます。

直結は、専用に構成された国際伝送経路より一般にコストが低く、利用頻度の低い国や都市を含む地域カバレッジの拡張に適しています。一方で公共ネットワークへの依存度が高く、通信事業者、接続場所、時間帯によって経路が変わることがあります。そのため、1回の接続結果を長期的に固定された結論として扱わないでください。

直結が常に第二の選択肢とは限りません。対象サービスとの距離が適切で、接続が安定し、アプリの応答も正常なら、そのまま直結を使えます。継続的な作業で明らかな中断が起きる、同じリソースを何度も再試行する、地域をまたぐ経路が不適切といった場合に限り、同じ地域の中継またはIEPLと比較してください。

Selection guide

用途別に国際回線を選ぶ

回線選びは、まず対象サービスの地域を決め、次に用途に合う回線タイプを選び、最後に実際のアプリで確認する順番が基本です。ノード名だけで判断したり、1回の失敗後に地域、クライアント、ネットワーク環境を同時に変更したりすると、原因を特定しにくくなります。

BROWSE

日常のウェブ閲覧と情報検索

一般的なウェブ閲覧では、東京、シンガポール、香港など、距離の近いアジア太平洋回線から試すのが基本です。ウェブリクエストは複数の短い接続で構成されることが多く、名前解決、ハンドシェイク、リソース読み込みの安定性に左右されます。よく使うサイトが北米に集中している場合は、米国西海岸向けを直接選ぶ方法もあります。近隣地域を経由してからサイト側で大陸間取得を行う経路を避けられます。

テストでは、実際に使うサイトを開き、本文、画像、ログインページを続けて確認してください。トップページが開くだけでは、サイト全体が快適に動くとは限りません。ログイン後のリダイレクト、認証ページ、静的リソースのドメインでは異なる経路が使われる場合があります。特定地域で一部のサイトだけに問題があるなら、地域を大きく変える前に、同じ地域で回線タイプを切り替えてみてください。

STREAM

動画視聴とストリーミング

動画視聴では、コンテンツの地域に合わせて出口を決めます。日本向けのコンテンツなら日本回線、米国向けなら米国回線から試してください。表の「対応」は、その地域の候補出口として利用できることを示すだけで、プラットフォームの会員範囲、コンテンツのライセンス、アカウント地域、再生ポリシーを変更するものではありません。

確認時は、トップページに目的のコンテンツが表示されるかだけでなく、実際の再生ページで画質変更、シーク、連続再生も確認してください。動画プラットフォームでは、ログイン、カタログ、画像、動画配信が別システムに分かれていることがあります。「サムネイルが見える」と「継続して再生できる」は別の確認項目です。問題がある場合は国を固定し、直結、中継、IEPLを比較して変数を減らしてください。

AIツールとストリーミング出力

AIツールのウェブ版では、ログイン状態、地域判定、長時間接続、ストリーミング応答が同時に関係します。出口地域は対象サービスの利用可能地域に合わせ、同じセッション中に国を頻繁に切り替えないようにしてください。長い会話、ファイルアップロード、継続的な生成では、同じ地域の中継とIEPLを優先的に比較するとよいでしょう。通常のウェブ閲覧より、一時的な接続変化の影響を受けやすいためです。

ページにはアクセスできるのに出力が途中で止まる場合は、アカウント状態、ブラウザーのセッション、回線を分けて確認します。まず契約情報を更新して同じ地域へ再接続し、それでも改善しなければ同地域の別回線へ切り替えてください。開発者がコマンドライン、IDEプラグイン、APIからサービスを利用する場合は、対象プロセスが実際にクライアント設定を使っているかも確認が必要です。ブラウザーが正常でも、他のプロセスが同じ出口を使っているとは限りません。

GAME

ゲームとリアルタイム通信

ゲームやリアルタイム通信では、名前が高性能に見える回線ではなく、サーバーの所在地域に合わせることを優先します。対象サーバーが日本なら日本向け、シンガポールならシンガポール向けから試してください。物理経路が迂回するほど、通信データが通過する区間は増える傾向があるため、近隣地域のゲームに大陸間の出口を標準設定するのは一般に適しません。

ログインや更新と、実際の対戦通信も分けて考える必要があります。ランチャーのダウンロード、アカウントログイン、ゲーム接続では異なるドメインやプロトコルが使われる場合があり、更新できた回線がリアルタイム通信に最適とは限りません。同じネットワーク環境で同じ地域の候補回線を比較し、実際のログイン、マッチング、継続操作の結果で判断してください。回線を切り替えた後はゲーム接続を再確立し、旧セッションが以前の経路を使い続けないようにします。

WORK

仕事、会議、リモート接続

仕事で使う場合は、まず企業サービスの設置地域を確認します。コードリポジトリ、クラウド管理画面、会議システム、リモートデスクトップはそれぞれ異なる地域にある可能性があり、適した出口も同じとは限りません。日常業務では主要システム用の地域を固定し、ログイン環境の変化を減らしてください。別地域のリソースが必要なときだけ用途に応じて切り替え、バックグラウンドで出口を自動変更し続けないようにします。

会議やリモートデスクトップは接続の継続性に敏感なため、中継とIEPLを優先的に比較できます。文書閲覧やメール同期は、近い地域の直結または中継から始めるとよいでしょう。重要なデータを転送する前に、小規模な接続テストを行い、対象システムへのログイン、アップロード、ダウンロードがすべて正常か確認してください。ホテル、コワーキングスペース、公共ネットワークで問題がある場合は、別の接続環境でも再確認し、現地接続の制限と遠隔回線の問題を切り分けます。

Diagnostic order

ノード切り替えの確認手順

無作為に切り替え続けるより、順番に確認するほうが効果的です。毎回1つの条件だけを変え、対象地域、回線タイプ、アプリの結果を記録すると、差が生じた原因を判断しやすくなります。

まず対象地域を確認
ウェブサイト、動画コンテンツ、AIサービス、企業システムが実際にどの地域を対象としているか確認します。地域を間違えると、接続自体が正常でも、プラットフォームが異なるコンテンツを返したり、機能の利用を拒否したりすることがあります。
地域を固定して回線タイプを切り替える
同じ国、または近隣都市の間で、直結、中継、IEPLを比較します。地域ポリシーの変化をテスト結果に混ぜず、経路構成の影響を確認できます。
アプリの接続を再確立
ブラウザーのタブ、デスクトップクライアント、コマンドラインのプロセスには、既存の接続が保持されることがあります。ノード切り替え後は対象ページを開き直すか、関連する接続を再起動し、新しい経路を確実に適用してください。
契約情報とクライアントの状態を確認
クライアントが最新の契約情報を取得し、選択した設定で接続済みになっていることを確認します。Windows、macOS、iOS、Android、Linuxでは、ユーザーパネルから対応するクライアントまたは契約情報を確認してください。
最後に現地の接続ネットワークを比較
複数の地域で同様の問題が起きる場合は、現在の接続ネットワークを変更して再確認します。ローカルルーター、ホテルのネットワーク、通信事業者の経路も接続に影響するため、ノード名だけを原因と決めつけないでください。