中国語圏のコミュニティで「AI イラスト向け VPN」を検索する人の多くは、Midjourney の公式サイトが開けないのではなく、もっと具体的な 2 つの場面でつまずいている。Discord クライアントが「接続中」を繰り返す、あるいは音声ルームに入ったのに相手の声が聞き取れない、というものだ。Midjourney は画像生成の入口を Discord の中に置いているため、1 回の生成でゲートウェイの常時接続、画像 CDN、音声 UDP の 3 経路を同時に通ることになる。どれか 1 つでも詰まれば体験は崩れる。本記事ではこの 3 経路を分けて解説し、自分で再現できる接続実測の方法、回線を選ぶ順序、そしてこの場面で本サービスが提供できることと、約束しないことを整理する。
Midjourney の接続は3 経路で成り立つ
Discord をひとまとめにして「速い・遅い」と判断すると、結論はたいてい外れる。Discord は性質の異なる 3 種類の通信を同時に流しているからだ。
- ゲートウェイの常時接続:クライアントは WebSocket で Discord ゲートウェイに接続し、メッセージイベントを送受信する。この接続が切れると画面は「接続中」のまま止まり、スラッシュコマンドも送れず、Midjourney の生成進捗も更新されない。
- API と画像 CDN:スラッシュコマンドや過去のメッセージは HTTPS の API を通り、生成結果は添付ファイルとして CDN に置かれる。回線自体は正常なのに画像がずっと読み込み中のまま、開いても画像が壊れて表示される場合は、この区間に原因があることが多い。
- 音声ルーム:音声と映像は WebRTC が担う UDP で流れるため、パケットロスやジッタの影響を Web リクエストより強く受ける。「テキストは送れるのに音声に入ると落ちる」のは、プロキシが TCP しか引き受けず UDP を扱っていないケースでよく起きる。
Midjourney の Web 版は別の入口で、ログインと生成は HTTPS で完結し、Discord のゲートウェイ常時接続には依存しない。ただし画像は同じく CDN から取得する。つまり「Web 版は使えるのに Discord では使えない」は矛盾ではなく、問題を特定の経路に絞り込んだだけのことだ。
回線種別の比較:直結・中継・IEPL 専用線
回線種別はこの 3 経路の上限を決める。3 つは単純な「速い・遅い」の順列ではなく、経路の性質の違いによるトレードオフだ。
| 回線種別 | 経路の特徴 | 音声ルームでの一般的な挙動 | 向いているシーン |
|---|---|---|---|
| 直結 | 海外ノードに直接接続し、公共の国際出口を通る | 夜のピーク時間帯はパケットロスやジッタが増え、音声が途切れやすい | 画像生成のみで音声には入らず、待ち時間を気にしない場合 |
| 中継 | 中継ノードに接続し、最適化された経路で出口へ抜ける | 直結より安定するが、実際の品質は中継区間の混雑状況に左右される | 日常的な画像生成とテキストチャンネル、たまに音声 |
| IEPL 専用線 | 国際イーサネット専用線で、公共の出口を通らない | 経路が固定されジッタが小さいため、長時間の音声でも安定しやすい | 長時間の音声コラボ、複数人が同時に画像生成する場面 |
はっきりさせておきたいのは、回線種別が影響するのは経路の品質だけで、Midjourney の生成速度そのものは変わらないという点だ。生成はサーバー側で順番待ちになる。クライアント側にできるのは、コマンドを送り、進捗を受け取り、画像をダウンロードできる状態を保つことだ。
音声ルームの接続実測のやり方
「実測」に専用の測定器は要らない。条件を揃えるだけでいい。同じチャンネル、同じ時間帯、同じ操作で、一度に変える条件は 1 つだけにする。地域・回線事業者・時間帯によって結果は大きく変わるので、以下に示すのは固定された数値ではなく、再現できる手順だ。
- まず回線を挟まないベースラインを取る。音声ルームに 5 分間入り、途切れやロボット声のような音がないかを確認し、チャンネル内で接続情報を開いて現在のリージョン・プロトコル・パケットロス統計を見る。
- 回線を接続して同じ操作を繰り返す。同じチャンネル、同じ時間帯、同じ 5 分間で、変えるのは回線だけ。端末もヘッドホンも変えない。
- 接続情報のプロトコルを確認する。回線経由ではなく直接 UDP と表示されているなら、その回線は UDP を転送しておらず、音声は加速されていない。
- 画像経路を測る。同じチャンネルで Midjourney に画像を生成させ、添付が現れてから完全に開けるまでの過程と、画像が壊れないかを見る。
- ゲートウェイ経路を測る。クライアントを 30 分以上オンラインのままにして、「接続中」の再接続表示が出ないか確認する。
- 次の回線に切り替え、2〜5 の手順を繰り返す。結果を 1 行に記録し、横並びで比較する。
- ✅ 音声が最後まで途切れず、接続情報のパケットロス統計も安定していれば、その回線の UDP 転送は機能している。
- ✅ 生成結果が出た直後に開ければ、画像 CDN の区間は通っている。
- ❌ テキストは正常なのに音声に入ると落ちるなら、帯域不足より先に、回線が UDP を転送していないことを疑う。
- ❌ メッセージは送れるのに画像がずっと読み込み中のままなら、CDN のドメインが回線を通っていないか、望ましくないノードに解決されている可能性が高い。
出口回線が効いているかの確認方法
接続できたことと、正しい経路を通っていることは別だ。次の 3 つの確認で、「つながっているように見えて実は通っていない」ケースのほとんどを潰せる。
出口アドレス:任意の IP 確認ページを開き、表示される所在地が選んだ回線と一致するかを見る。デスクトップではシステムプロキシと TUN モードで挙動が異なり、Discord は独立したプロセスなのでブラウザに追随するとは限らない点に注意する。
ドメイン解決:DNS リーク検出ページで、リクエストが最終的にどのサーバーで処理されているかを見る。解決が契約中のプロバイダ側で行われていると、CDN が近いが最適とは言えないノードを指し、画像の読み込みが遅いという形で現れる。
アプリ別の確認:クライアントがアプリ単位の分流に対応しているなら、Discord・ブラウザ・ローカルの描画ツールがそれぞれどの経路を通っているかを個別に確認する。
ブラウザだけで測っても意味がない。Discord クライアント、Midjourney の Web 版、ローカルの描画ツールは別々のプロセスだ。確認はそれぞれで行い、ブラウザの結果から残り 2 つを推測しないこと。
分流ルール:Discord は回線経由、ローカルツールは直結
全部をプロキシに通すのが一番手軽だが、ローカルの描画ツールまで無駄に遠回りして遅くなる。
- ドメイン単位で振り分ける:discord.com、discord.gg、discordapp.com、discordapp.net を回線経由に。midjourney.com は使う入口によって決める。
- プロセス単位で振り分ける:デスクトップクライアントはプロセス単位のマッチングが確実で、子プロセスが張る接続を取りこぼしにくい。
- UDP もまとめて通す:分流ルールで UDP を落とさないこと。ルール層で音声トラフィックが止められても、画面上にはほとんど表示が出ない。
- ローカルサービスは直結:Stable Diffusion WebUI や ComfyUI のようなローカルツールが待ち受けるポートを直結リストに入れる。そうしないとループバックの通信が一度外を回って戻ってくる。
回線の地域と種類はグローバルノードページを参照して選べます。同ページでは地域ごとに IEPL 専用線・中継・直接接続の別が示されています。
プロトコル選択:音声利用では UDP 対応が暗号化より重要
音声ルームは UDP で流れるため、プロトコルが UDP をそのまま運べるかどうかが、暗号化アルゴリズム以上に体感を左右する。
- Shadowsocks:軽量で UDP 転送に対応するが、サーバー側で明示的に有効化する必要がある。有効にすれば音声も通常どおり回線を通せる。
- VMess:TCP が主体で、UDP は追加のカプセル化が必要になり、オーバーヘッドと遅延が増える。音声用途では有利とは言えない。
- VLESS:それ自体は暗号化を内蔵せず、TLS に載せて使う。設定が適切なら非常に軽い。UDP はこちらも別途有効化が必要。
- Trojan:通常の HTTPS 通信に偽装するため、中間装置に寛容で、ネットワーク環境が複雑な場合に向く。
- Hysteria2 / TUIC:QUIC ベースで UDP をそのまま運ぶ。弱い回線やパケットロスが多い環境では音声が安定しやすい。ただしサーバー側で対応する UDP ポートを開放しておくことが前提だ。
要するに、音声ルームで一緒に画像生成する時間が長いなら、UDP をネイティブに扱えるプロトコルを優先する。テキストチャンネルでコマンドを送り画像を受け取るだけなら、プロトコル間の差は思うほど大きくない。
VPN の選び方と本サービスのスタンス
ここまでの判断基準をまとめると、選ぶ順序はおおむね次のとおり。まずプロトコルが UDP を転送できるかを確認し、次に回線種別、最後にノード数を見る。ノードが多いことは経路が良いことを意味しない。ジッタの小さい専用線 1 本のほうが、混雑した直結回線を何本も並べるより役に立つ。
この基準で見た本サービスの構成は次のとおり。90+ の国・地域、160+ の回線を用意し、種別は IEPL 専用線・中継・直結をそろえている。音声ルームは上記の手順で 1 本ずつ実測してから選べばいい。1 アカウントで台数は無制限、デスクトップとスマートフォンを同時にオンラインにできるので、音声のために別契約を増やす必要はない。登録はユーザー名とパスワードだけで、メールアドレスは不要。ログは記録しない。7 日間の理由を問わない返金に対応し、支払い方法は Alipay・WeChat Pay・USDT。
結論:画像生成だけで音声に参加しないなら直結回線で十分。音声ルームで長時間コラボするなら、IEPL 専用線か UDP をネイティブに扱うプロトコルのほうが向いている。判断材料は「速い気がするか」ではなく、接続情報に表示されるプロトコルとパケットロス統計だ。
よくある質問
回線を接続しているのに Discord が「接続中」のままになる場合は?
まず、その回線が UDP と常時接続を引き受けているかを見る。長時間保持される WebSocket をリセットするネットワーク環境もあり、回線を変えるか TCP ベースのプロトコルに切り替えると復旧することが多い。Discord だけつながらずブラウザは正常なら、分流ルールにゲートウェイのドメインが漏れていないかを優先して確認する。
Midjourney の Web 版と Discord では生成結果が違う?
同じアカウントなら生成はどちらもサーバー側で行われる。違いは入口だ。Web 版は HTTPS で完結し、ゲートウェイ常時接続の区間がない。Discord はメッセージ配信が 1 層増え、画像は同じく CDN から取得する。使いやすいほうを使えばよく、「より本格的」という理由で無理に片方へ決める必要はない。
スマートフォンだと音声ルームから切れやすい?
モバイル回線は基地局を切り替える際に出口アドレスが一時的に変わり、OS 側の VPN はトンネルを張り直す必要があるため、その間だけ音声が途切れる。Discord をアプリ単位のプロキシ対象にして回線経由のみにし、バックグラウンド動作を許可しておくと、こうした切断を減らせる。