1 背景とゴールをそろえる
2026 年時点でも、画像生成 AI は検索・業務の両方で需要が高く、Midjourney はその代表格の一つです。利用者がつまずきやすいのは、モデル品質以前に、Discord クライアント／Web、公式サイト、決済ページが別々のドメインへ HTTPS を張ることです。システムプロキシ、環境変数、TUN の有無がバラバラだと、同じアカウントでも「Discord 上の生成は成功するのに、ブラウザの会員ページだけ名前解決が変」「モバイル公式アプリは通るのにデスクトップだけ別出口」といった切り分けが難しくなります。
本稿のゴールは、帯域を無闇に広げることではなく、Rule モードで Midjourney 周辺と Discord 周辺のトラフィックを、意図したアウトバウンドへ集約することです。実際のホスト名はアップデートで増減するため、最終的には Clash の接続ログで SNI を確認し、自前の短いサフィックスリスト＋ログ追記で保守する運用が現実的です。
2 ChatGPT／Claude 向け記事との棲み分け
当ブログでは、OpenAI はChatGPT／OpenAI API 向けの記事、Anthropic はClaude 向けの記事のように、単一クラウド事業者の API と Web を中心にしたドメイン束を扱っています。Midjourney の典型フローはそこにDiscord というコミュニティ基盤（IM・サーバー・音声・メディア CDN）が加わる点が大きく異なります。つまり「api.openai.com だけ追えばよい」タイプの整理とは別に、discord.com 系のゾーン全体とmidjourney.com 系の両方を設計に入れる必要があります。
また、画像生成のプレビューやアセット取得は、チャット本文よりメディア用ホストへの並列リクエストが増えやすく、片方だけ DIRECT に落ちると「テキストは返るが画像が出ない」症状に見えることがあります。Google の Gemini を併用する場合はGemini 向け記事と対で読むと、ベンダーごとの出口分離がしやすくなります。
3 Discord クライアント／Web が触るホスト
Discord は Web、デスクトップ、モバイルでスタックが異なりつつ、典型的には次のような単位でサフィックスを束ねます。実ホストは更新されるため、失敗時は必ずログの SNI を正としてください。
- メインゾーン：
discord.com、discordapp.com。旧名と新名が混在する期間があり、片方だけルールに入っていると遷移で失敗することがあります。DOMAIN-SUFFIXでゾーンを覆うのが無難です。 - 招待・短縮：
discord.ggは招待リンクで頻繁に現れます。コミュニティ参加の導線でブロックされると、Midjourney 公式サーバーへの参加自体が止まります。 - メディア・CDN：
cdn.discordapp.comなど、添付やアバター取得に使われるホスト。タイムラインは表示できるのに画像だけ出ない症状は、ここが意図せずDIRECTや別グループに落ちているときに起きやすいです。 - リアルタイム通信： 音声・画面共有まわりは追加のエンドポイントや UDP の扱いが絡みます。プロキシの種類や TUN の範囲によって挙動が変わるため、まずは HTTPS の SNI が期待どおりのセレクタに乗っているかを確認します。
GEOSITE の「Discord」カテゴリは便利ですが、更新タイミングや粒度で漏れが出ることもあります。安定性を優先するなら、ローカルの明示ルールを上に置き、購読リストの広い MATCH より先に評価させます。
4 Midjourney 公式ドメインと Web 体験
公式サイトやドキュメント、ギャラリー、会員向けの案内は midjourney.com 系にまとまることが多く、DOMAIN-SUFFIX,midjourney.com でゾーン全体を覆うのが起点になります。サブドメインが増えた場合は接続ログで追記してください。ブラウザのプライベートウィンドウと通常ウィンドウで Cookie の状態が違うと、ログイン周りだけ別症状に見えることがあるため、アプリ横断で同じルール・同じ DNS 設定かを確認します。
画像生成の結果表示は、単一の JSON 応答より複数ホストへの並列取得になりやすい点は、先述の Discord CDN と同様です。ここでは「Midjourney 用セレクタ」と「Discord 用セレクタ」を分けるか、初回は同一セレクタに集約してレイテンシを比較するかを選べます。遅延特性の違うノードを意図的に分ける場合でも、ログで漏れがないことを先に確認してください。
5 課金・サブスク・決済ページ
プラン変更や請求履歴は、事業者のメインサイトとは別に決済プロバイダのドメインへ遷移することがあります。代表的には stripe.com や stripe.network などが挙げられますが、実際に表示されるホストはフローとアカウント状態で変わります。症状が「Midjourney の画面は開けるのに、カード入力の段階だけ失敗する」場合は、決済ホストが別ルールに落ちていないかをログで確認してください。
セキュリティ上、決済ページは企業プロキシの TLS インスペクションの影響を受けやすく、証明書エラーはルール以前の問題であることがあります。職場端末では IT ポリシーとあわせて切り分けてください。ルールに決済ドメインを足す場合は、信頼できるリスト源とチーム内のレビューを前提にし、不要な広域マッチは避けます。
6 ルールモードとプロキシグループの置き方
推奨は mode: rule です。PROXY-MJ-DISCORD のようなセレクタまたは url-test 付きグループを一枚挟み、遅延の安定したノードと、帯域はあるが不安定なノードを分けておくと、画像の長めの生成待ちや Discord のスクロールを比較しやすくなります。グローバルモードは国内向けサービスまで遠回りし、ダイレクト固定では公式サイトだけ失敗する、というジレンマが出ます。
購読テンプレートに既に「国外 SNS」や「国外 AI」ブロックがある場合は、その直前に Discord／Midjourney 向けの明示ルールを置き、意図せず別タグのノードへ飛ばないようにします。CLI やサンドボックスから API を叩く場合は、TUN モードで仮想 NIC レベルに揃えると、環境変数の HTTPS_PROXY とのばらつきを減らせます。
7 YAML に書くルール例と Rule Provider
以下はイメージです。proxy-groups 名やインデントは手元の設定に合わせてください。コメントは英語のみとします。
# Example: route Discord + Midjourney + common payment hosts to one selector
rules:
- DOMAIN-SUFFIX,discord.com,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,discordapp.com,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,discord.gg,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,discord.co,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,midjourney.com,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,stripe.com,PROXY-MJ-DISCORD
- DOMAIN-SUFFIX,stripe.network,PROXY-MJ-DISCORD
# Optional: remote rule-provider (path/interval are examples)
# rule-providers:
# mj-discord:
# type: http
# behavior: classical
# url: "https://example.com/rules/mj-discord.txt"
# path: ./rules/mj-discord.yaml
# interval: 86400
# rules:
# - RULE-SET,mj-discord,PROXY-MJ-DISCORD
Rule Provider を使う場合も、リモートリストの中身が信頼できるか、更新間隔とローカル追記ルールの優先順位を確認してください。Mihomo／Clash Meta 系は上に書いたルールが先に評価されるため、細かい DOMAIN を上に、広い GEOIP や MATCH を下に置くのが定石です。チームでリストを共有するなら、classical 形式の Rule Provider にホストを集約し、ローカルでは RULE-SET を先に参照する構成も有効です。
8 DNS・FakeIP・TLS をセットで見る
Discord と Midjourney をまたぐとホスト数が増えるため、DNS の答えが期待とズレると「ブラウザでは開けるのに Discord だけ名前解決が変」という現象が起きやすくなります。Mihomo では DoH、FakeIP、fallback-filter の組み合わせが定番です。設定の細部はMeta カーネル DNS の実務記事に譲ります。Clash の DNS セクションと OS の DNS を二重管理しないこと、TUN と DNS ハイジャック併用時にローカル開発用ゾーンを DIRECT に残すことが安定の鍵です。
TLS の観点では、SNI が discord.com でも、企業プロキシによるインスペクションで証明書検証が失敗するケースがあります。エラー文言が証明書関連なら、まず社内ポリシーと OS の信頼ストアを疑ってください。逆にルールで意図せず DIRECT に落ちていると、RST やタイムアウトとして現れます。
9 動作確認の手順
ブラウザで midjourney.com を開き、ログインと会員向けページの表示が一通りできる状態を基準にします。続けて Discord（Web またはデスクトップ）で同一アカウントの操作を行い、接続ログに discord.com／discordapp.com 系、midjourney.com、必要に応じて stripe.com などが現れるかを見ます。課金フローを試す場合は、テストモードや小額の範囲で、公式の案内に従ってください。
セレクタの切り替え
セレクタで別アウトバウンドへ切り替え、再現性を比較すると、ノード側の問題かルール側の問題かを切り分けやすくなります。画像生成は待ち時間が長いため、パケット損失の大きいノードでは UI 上「途中で止まった」ように見えることがあります。
10 トラブルシューティング
- Discord は通るが公式サイトだけ失敗：
midjourney.com系がルールに含まれているか、より広いルールに先にマッチしていないかを確認します。 - 画像やプレビューだけ表示されない： CDN 系ホストが
DIRECTや別グループに落ちていないかをログで確認します。 - 招待リンクだけ開けない：
discord.ggやリダイレクト先がルールに含まれているかを確認します。 - 決済ページだけ証明書エラー： ルールよりも企業プロキシやローカルセキュリティ製品を疑います。
- 新しいサブドメインで失敗： 接続ログに出た SNI を
DOMAIN-SUFFIXまたはDOMAINで追記し、Rule Provider のリストにも反映できるか検討します。 - ルールを足したら国内サイトが遅くなった：
GEOIP,JP,DIRECTなど直行ルールとの順序を見直し、誤マッチがないか確認します。
11 まとめ
Midjourney を「公式サイトだけ速くする」のではなく、Discord コミュニティと midjourney.com 系、必要なら決済ホストまでをルールと DNS で一貫させると、ブラウザ・デスクトップ・モバイルをまたいだ再現性が上がります。ChatGPT や Claude のような単一クラウドの API 中心記事とは異なり、IM・CDN・コミュニティ導線が加わる点がポイントです。粗い GEOSITE だけに頼ると漏れと過剰マッチの両方が出やすいので、DOMAIN-SUFFIX とログベースの追記、必要なら Rule Provider で保守性を補います。
まずは手元の YAML に Discord／Midjourney の代表サフィックスと、課金で観測したホストを追記し、接続ログで漏れがないか確認してください。DNS の細部はDNS 実務記事に譲ります。ルール分流とログの読み方さえ身につけば、同じ考え方を他の「コミュニティ＋クラウドサービス」組み合わせにも転用できます。
単機能の軽量プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、複数ドメインにまたがる HTTPS セッションや画像・メディアの並列取得に強い場面が多いです。画像生成を日々のフローに組み込むほど、その差は試行回数と体験の安定性に直結します。
