Midjourney Web が読み込みで止まる？Clash 分流・ノード

1. 「ずっと読み込み」が出やすい理由

Midjourney の Web は、単一オリジンのアプリではありません。ログインや課金まわり、生成ジョブの状態取得、ギャラリーのメタデータ、サムネイルやプレビュー用のバイナリ取得などが、異なるホスト名に分散しがちです。ここで Clash の rules: において、目立つ midjourney.com だけが PROXY に乗り、REST や WebSocket 相当の API ホスト、あるいは 画像配信用 CDN が GEOIP や広い DOMAIN-SUFFIX、MATCH によって DIRECT に抜けると、ブラウザは「枠は描けるが中身が来ない」状態になり、ユーザーから見ると永遠に回るアイコンに見えます。

これは YouTube で本丸と googlevideo の経路が食い違うときと同型です。また、出口の 地域や ASN と CDN のエッジ割当が噛み合わないと、TLS は完走してもアプリケーションレイヤでタイムアウトが続く、という見え方にもなります。

本稿はサービス規約違反や未承認の地域回避を推奨するものではありません。公式の利用条件とプライバシー方針に従い、自宅やオフィスでの接続品質を整える一般論にとどめます。

2. 想定されるホスト名と CDN

以下は切り出しの出発点であり、フロントの実装やインフラ構成はアップデートで変わり得ます。症状の瞬間に Clash ログの Server Name と、ブラウザ開発者ツールの「ネットワーク」一覧を正として、自分用ルールへ追記してください。

公式 Web：midjourney.com、www.midjourney.com など
認証・決済・IdP：ログイン連携で現れるサードパーティ名（ログに出た FQDN に合わせる）
API・リアルタイム更新：api. や graphql 風のサブドメイン、長めのホスト名
画像・静的配信：*.cloudfront.net 風、オブジェクトストレージ由来の長いホスト、画像最適化 CDN
計測・フラグ：A/B やエラー送信用のドメイン（ブロック過多で UI が壊れないか要確認）

ログの見方

改善の早道は、不調が出る操作の直前からログを有効化し、どのホストがどの policy にヒットしたかを見ることです。PROXY に揃えるべき行が DIRECT になっていないか、より上位の GEOIP や購読ルールに先食いされていないかを確認します。ストリーミング系の「本体と配信の一貫性」の考え方は、Disney+ 向け記事とも共通です。

3. Clash の分流ルール例

Mihomo／Clash Meta 系では rules: に DOMAIN-SUFFIX や RULE-SET を重ね、必要に応じて GEOSITE やサブスクルールを併用します。以下は学習用の最小例です。本番では必ずログの実名で置き換えてください。

# Example only — replace with hosts from your client / browser logs
rules:
  - DOMAIN-SUFFIX,midjourney.com,PROXY
  - DOMAIN,cdn.example.invalid,PROXY
  - MATCH,DIRECT

DOMAIN-SUFFIX,cloudfront.net のような広いサフィックス一括 PROXYは、他サービスの大容量転送まで巻き込みやすいです。最終的には、ログに出た FQDN を DOMAIN 行で足す運用が安全です。公開 RULE-SET だけでは更新ラグで取りこぼすことがあるため、個人用の短い追記ファイルを用意しておくと、Midjourney のような頻繁に裏側を更新するプロダクトと相性がよいです。

コアの設定項目の整理は Clash のドキュメントと併読すると、proxy-groups とルールの役割分担を誤りにくくなります。

注意：DOMAIN-KEYWORD などのキーワード系ルールは誤爆しやすいです。可能な限り、ログで確認した正確な FQDN から作ってください。

4. ノード選択と「生成ジョブ」の待ち時間

低遅延だけが正解ではありません。AI 画像の生成はサーバ側キューとフロントのポーリング／プッシュの両方に依存し、出口 IP の頻繁な切り替え（自動フェイルオーバー）が入ると、セッションや帯域制御の都合でさらに不安定に見えることがあります。実務的には、同一プロファイル内で往復が落ち着き、切断が少ない出口を一時的に手動で固定し、ギャラリーや新規生成が通るかを見てから、自動策略へ戻すのが扱いやすいです。

症状	ありがちな原因	先に試すこと
ヘッダーは出るが一覧が空のまま	一覧 API 用ホストだけ別経路	ネットワークログで API 名を `PROXY` へ
サムネだけ出ない／遅い	CDN だけ `DIRECT`	該当 CDN ホストを策略に束ねる
生成ボタン後ずっとスピナー	ジョブ状態取得が別出口	同じ操作で SNI を比較しルール順を調整
TLS エラーが混じる	SNI と実経路の不整合	TLS 切り分け記事を参照

url-test 系が「計測は速いが画像転送に不向き」な出口ばかり選ぶ場合は、interval・tolerance・lazy の整理で挙動を詰められます。

5. DNS・Fake-IP との切り分け

Fake-IP モードでは、名前解決とルール突き合わせのタイミングが絡み、ブラウザが握っている名前とプロキシが評価している名前がすれ違うと、「DNS は成功しているのに UI だけ不安定」に見えます。fake-ip-filter と分岐ルール、dns セクションの矛盾を減らすと改善しやすくなります。

ブラウザ側で DoH を有効にしていると、OS プロキシと Clash 内蔵 DNS の二重解決に気づきにくいです。一時的に DoH を切って再現性を比較し、nameserver の想定と揃うか確かめてください。偽陽性の整理は fake-ip／filter 記事に任せると、本稿の個別ドメイン行を増やしすぎずに済みます。

ヒント：症状の出るプロファイルを維持したまま、シークレット窓（拡張なし）で再現するか比較すると、広告ブロッカーの過剰ブロックを切り分けやすいです。

6. 動画・音楽・チャット記事との補完関係（画像生成の垂類）

当サイトでは Suno のように音声生成 Web と CDN を揃える記事、OpenAI Sora の動画系ドメイン分流、Character.AI のチャット主体のドメイン固定などを掲載しています。それらはそれぞれストリーミングや長文 SSE、会話 API に寄ったホスト集合ですが、Midjourney は大量の画像サムネイルとメタデータ APIが前面に出やすい点が違います。大容量モデル取得全般に近い整理は、Hugging Face の CDN 記事とも親和性があります。

コアのソースやライセンスは GitHub 上の公式情報で確認できます。一方、クライアントのインストールの主導線は当サイトのダウンロードページを推奨します（OS 別の導線が整理されています）。

7. セルフチェック

上から順に試せる順序です。

GUI・コアの更新：古いクライアントはログ形式や挙動が古い。最新系へ。
システムプロキシと TUN：ブラウザ全体が同じ表に乗っているか。
ルールのヒット：操作中の SNI／ドメインが想定 PROXY か。
API・CDN ホスト：一覧・画像だけ DIRECT に抜けていないか。
ノード：帯域と安定性の妥協点。必要なら手動で固定して再試行。
拡張・DoH：二重解決やブロックで壊していないか。

8. まとめ

Midjourney の Web は、midjourney.com という「見えている入口」だけを PROXY にしても完結しない場面が多く、API と画像 CDN、認証まわりの出口の一貫性がボトルネックになりやすいです。ログの実名に合わせて PROXY を揃え、ノード選択を生成待ち向けに少し「安定重視」へ寄せ、DNS の二重化を減らすと、永続スピナーや部分的な空白表示は大きく減らしやすくなります。2026 年も、生成系 Web を快適に使うには、分流ルールを育てる習慣がそのまま生産性に効いてきます。

他の多機能プロキシと比べ、Clash 系は接続とルールの対応をログで追いやすく、短い試行で改善幅を把握しやすい面があります。ルールを整備しやすいクライアントとして使う価値が、そのまま AI 画像ワークフローにも乗ります。

→ Clash を無料ダウンロードし、Midjourney 利用時の経路を試す