2026：Runway ウェブと Gen が重い？Clash で CDN・アカウント／OAuthドメインを分流する実測手順
Runway は海外の創作クラスで注目度の高い AI 動画プラットフォームの一つであり、検索クエリにも「サイトが開かない」「ログインできない」「ブラウザ版の動きがカクつく」といった状態ベースの悩みが多く載りやすい体験です。一方でサービス側は SPA 相当の構成で、ランタイムのアプリ用ホスト・静的アセット／メディア配信用の CDN／エッジ・ログインおよびサブスク課金それぞれが別 FQDNになりやすい典型です。このため Clash（多くの場合は Clash Meta／Mihomo を含む構成）での分流ルールとして runwayml.com 本体だけ縛っているとページ枠だけ成功し、ジェネレーション用のwebsocketや動画キュー、あるいは OAuth まわりのリダイレクトだけ落ちている、という部分的成功に見えることがあります。本稿は OpenAI Sora と Midjourney と同じ「海外クリエイティブサービス」を扱いつつ、動画ワークフローの WebSocket とメディア帯が前面に出やすい点を差異として整理します。以下のDOMAINやRULE-SETとの出会い順は出発例であり、エッジの名称はサービス側の更新や地域ロールアウトで変わり得ます。自分のコンソールの接続ログとブラウザの開発者ツール／ネットワークに出た FQDN を唯一の根拠として育ててください。利用規約と職場・学校の規程には必ず適合させてください。
症状を三層に分ける：UI・メディア・認証／課金
(1) ランディングやプロジェクト一覧は概ね問題ないが、タイムライン内のプリロードだけが永遠にスピナー、(2) Gen 系でのキュー状態や結果プレビューの取得だけがタイムアウト、(3) SNS ログインやワークスペース招待のリダイレクトだけblockedやcertificate系に見える、といったとき、原因はすべて同じとは限りません。まず開発者ツールのネットワーク列で失敗レスポンスごとのホスト名を眺め、アプリ側のコンソールに表示されるwebsocketの接続先がサービス直下か、あるいはエッジ専用の別名まで分かれたかを切り離します。また OpenAI ChatGPT／APIの整理はChatGPT と Clash の記事。YouTube に近い視聴帯のノード評価の型は単純転用せず、キュー処理と転送サイズ優先になりがちです。用語や画面遷移の土台としてはClash チュートリアルを、複数サービスとのバランス付けとしてはRULE-SET と手書き行の並び順をカスタムルール解説にも当てます。
分流の下地：RWGenProxy のような名前付きグループへ寄せる
RULEで指す先として雑なProxyグループだけを使う運用でも動きますが、用途ラベルを付けたselectまたはurl-testを切り、アプリ側のログで名前をひとそろいにしておくと、運用ログを後から読んだときにも他サービスの出口と混ぜにくくなります。BBRやHysteriaといった転送レイヤとは別次元で、「同じ時間帯に転送キューだけが詰まる」ときはブラウザ内の並列フェッチ競合にも注意し、コンソールの並列実行数やタブ単位で切り替えられるかを一度見ます。proxy-groupsの型についてはグループ構成の共通パターンへ誘導できるproxy-groupsガイドがあります。
完全一致だけでなくインデントや不可視空白が混じっていないかを、YAML が苦手でも単純差分検出できるエディタで一度見ると、環境による「だけが通らない」系の地雷を回避しやすいです。
ドメイン束ねの出発線：runwayml.com からでも足りない理由
サービス側の実装によりますが、アプリ機能のXHRやfetch、ストリーム系、プレビュー用のオブジェクト保管がeTLD+1の外に出やすく、CDN も共通エッジだけでなくサービス単位でCNAME が別名になるケースがあり得ます。そのため単純なDOMAIN-SUFFIX,runwayml.com一発では足りなくてもおかしくありません。とはいえ最初の一行としてサービス側の明示サフィックスは上段へ置き、そのあと自分のコンソールに出ているFQDNだけを増やしていく運用が、将来の名前変更にも追従しやすいです。コミュニティ配布のRULE-SETにGEOIPまたはGFW系の広いセットを並べているなら、この用途向けDOMAINまたはDOMAIN-KEYWORD類をRULE-SET の前へ持ってくる考えは、前述の競合しない順番に直結します。ストリーム用途の並びの一例はNetflix とノードの記事ですが、Runway が地理制限コンテンツを前面にしない限り、そのまま複製しないで構いません。
# Examples only — names like RWGenProxy replace with yours; derive hostnames from YOUR logs
rules:
- DOMAIN-SUFFIX,runwayml.com,RWGenProxy
- DOMAIN,app.runwayml.com,RWGenProxy
# If Network tab shows a separate API or queue host — list explicitly before GEOIP catches it
# - DOMAIN-SUFFIX,cdn.example.edge,RWGenProxy
# Login / OAuth redirect hops may appear on unrelated eTLD+1 — only add AFTER verification
# - DOMAIN-SUFFIX,authentication-provider.example,RWGenProxy上段のDOMAIN-SUFFIX,stripe.*のような広い適用まで同時に持ち込むとほかサービスの決済でも同じ出口を共有してしまうため、その前に当該画面のiframeだけという単位でのネットワーク列を見やすくし、ログに載った名前と突き合わせます。
DNS と fake-ip：名前付き IP が規則に合わないとき
ルール行が並んでもレスオルバが異なる経路になるとwrong IPが返り、画面上はDIRECTに見えるのに期待と異なる名前にマッチしないまま処理されることがあります。Mihomo側のdnsでlistenとtun/stackの組み合わせ、およびnameserver-policyでの上書き範囲を、一度だけではなく問題が出ているホストだけ順に確認します。またWSL側とブラウザ側で異なる名前解決窓がある場合には、コンテナ側の/etc/resolv.confが自動差し替えで再び競合しないかをチェックすると扱いやすくなります。Windows とブラウザの乖離だけを切り離したガイドはUWP とプロキシにもあります。UDPはこのテーマだけで問題になるときもあれば問題にならないときもあるので、まずログのL4 と失敗タイプから判断します。
HTTPS／TLS と Web の速度知覚
動画ワークフローではBLOB 転送だけでなくXHRの列と並列キューが重なるため、体感はMbpsだけでは説明しきれません。コンソールの開発者ツールでキュー状態が長時間queuedのままであれば、アウトバウンドのポート枯渇よりもサービス側の並列処理枠と地域の可能性も頭に置いたうえで、まず自分の側でDIRECTとPROXYでの差を比較すると切り分けが早いことが多くなります。ここでの出口はGEOIP,!cn,RWGenProxyだけに寄せ過ぎるとほかサイトまで同様に広がります。その意味でRULE は用途別細分化が肝です。また広域 VPN と Clash での粒度の違いは比較の整理が参考になります。
段階実測：Rule ログを正として育てる手順（推奨フロー）
-
1
ベースラインデータをブラウザで取る
同一端末同一ブラウザで、Clash が無効またはシステム直結プロキシだったときも含め開発者ツールのネットワークに残る
名前とInitiatorタイプを並べます。XHR／イベントストリーム／webp／videoが混線していないかをまず一覧化すると、分流の順番検討に迷いません。 -
2
Rule に戻しコンソールの Rule ログを読む
各失敗イベントについてFQDN／採られたポリシー名／タイムスタンプを突き合わせ自分のリストに載っていないホストがあるかを見ます。そのホストだけを試しに
DOMAINまたはDOMAIN-SUFFIXへ追加し、その直後だけをもう一度同じユーザー操作へ戻していきます。広いセットの前への持ち替えが必要かもここが分岐点になります。 -
3
認証のみ失敗するときだけ OAuth と課金列を確認
ブラウザのログインウィンドウだけが別ウィンドウに飛んだり、サービスとは別ブランドが混ざる場合は、その
locationヘッダチェーンにあるeTLD+1を拾い込みDOMAINで束ねます。名前が頻繁に変わりそうなら広いサフィックスにする代わりに自分のワークスペースで再現ログを一定期間だけ保持し、増分で更新する運用になります。 -
4
RULE-SET と
RULE-PROVIDERとの位置を定期的に確認コミュニティのオンラインセットは更新頻度が高く、まれに意図と逆の並びが入るときがあります。用途別明示行を
prepend相当の順に置くか、セットを下位側に退かすかがテーマになります。その判断は自分のリストとMETAのバージョン両方への理解が効きやすく、まずコンソールのMETAログでコンフリクトを視覚的に読むだけでも効果があります。
このサイクルを機能アップ後も年に数回はやり直せる状態にすると、CDN 名前が差し替えられても短期で復帰できるようになりやすくなります。
よくある質問（短答）
Runway と Sora と Midjourney の記事どれから読むべき？
動画中心でワークフローとキュー優先なら本稿。OpenAI 側のモデルセットとプラットフォームは Sora 向け記事、静的画像・CDN の混線が主なら Midjourney 向け記事の順で迷いません。
GEN モデル側でwebsocketだけ失敗することがある
WSSの宛先FQDN単位でDOMAINまたはDST-PORT含むMATCHとの兼ね合いを見ます。まれにポートがサービス側で増殖している場合がありますが、広い許可はしないでコンソール列を再観察します。Zstdやコンテンツ圧縮の列でブロックされていないこともチェックだけ。
購読のRULE-PROVIDER urlが届かなくなったとき
DIRECT で届かないときはprofiles側のタイムスタンプだけでなく、fetch のログでDNS と TLSのどちらで止まっているかを切り分けます。すべてのアウトゴーイングに影響するなら GEOIP,!cn,DIRECT だけを疑うのではなく、特定の購読 URL のホストだけ明示します。
まとめ
AI動画ワークフローと海外ツール依存が重なる時代に、サービス側のCDN・認証・アプリAPIが離れたFQDN線へ伸び続けるとき、ユーザー側でできるのはほぼ経路情報のログに基づく整理です。RULE の順とDNSの一致まで含められれば、「トップだけ速い」のような知覚上のねじれにも立ち返りやすくなります。OpenAI と Google 系とは異なるセットを前提に済ませたいときは前述の関連記事を使い名前の取り込み済み状態を混ぜないことも運用効率になります。
クライアントの更新と実行ファイルの参照は常に本站のダウンロードページへ寄せ、そのうえで GitHub が検証ソースかどうかを見る順番とすると読者側の選択もシンプルです。ソースとバイナリの入口が二重にあると運用ログが複雑化しがちであり、サイトを軸に揃える意義は単なるリンク集の整理以上に強い運用ログの単純さにあります。また一般的な複数ノード自動振りとは別に、アプリ側のワークスペース設定が地域を固定している場合にもFQDN列は変わります。そのため自分のワークスペースで再ログインして取り直すこともセットです。
端末を丸ごと常時迂回する構成より、用途別に規則を書き換えやすい設定ファイルの透明性が高い側がメリットになっている場面は多く、まさにそこへMihomo 系との相性が重なってきます。そのため自分のワークフローに必要なだけのルールセットを育てる姿勢は、長く使うときにサービス側の細かな変化にも追従できるでしょう。構成を広げずに RULE だけ触りたいときは前述の関連記事群とセットで順を追ってください。
OpenAI GPTとHugging Faceとはモデル側の視点でも接続先セットが異なるため、クロスセットのコピーはしないのが鉄則です。あわせて Hugging Face Hubはオープンウェイトモデルの集約側の寄せ方が強く、Runway と比べればMLOps の粒度も異なります。