症状の整理：主ドメインは通るのに「回り続ける」理由

ブラウザや公式アプリで Reddit を開いたとき、画面上はローディングの円が回り続けるだけでフィードが出てこない、サムネイルが真っ白、コメント欄だけ空のまま——といった報告は、コミュニティ規模が大きいサービスでは珍しくありません。原因が一つに決まるわけではありませんが、プロキシ利用者にとって再現しやすいパターンは ホスト単位で出口が割れている ことです。たとえば www.reddit.com の HTML は速いノードへ流れている一方で、CSS／JS を配る redditstatic.com だけ別の遅い経路や不安定なチェーンに落ちると、描画は途中で止まったように見えます。

さらに厄介なのが ボット対策の検証フロー です。hcaptcha.com や newassets.hcaptcha.com、reCAPTCHA まわりの www.google.com／www.gstatic.com／recaptcha.net などが、メインの Reddit ドメインとは別ポリシーに乗ると、チャレンジの iframe だけ読み込み失敗し、以降の API 呼び出しがすべて待ち状態に見えることがあります。ユーザーから見れば「Reddit が重い」一つの症状ですが、開発者ツールのネットワークタブや Clash の接続ログでは 別々の SNI として現れます。

Clash 系クライアントは接続ごとに rules を上から評価し、最初にマッチした行でポリシーを決めます。Reddit のような大規模サイトはサブドメインと CDN の組み合わせが増えやすく、サブスク付きの巨大ルールセットだけに任せると「意図しない行が先に当たる」「カテゴリの定義が古い」といったずれが起きます。症状をホスト名に分解できれば、MATCH の手前に差し込む明示ルールの位置も自然に決まります。

ℹ 観測のコツ：フィード表示時・画像展開時・ログイン時で接続ログのドメインを比較し、どの層で滞留しているか をメモします。CAPTCHA が絡む場合は、その直前に出たホスト名を優先的に追います。

Reddit 周辺の層：本体・静的・メディア・API

実務では次のように層を分けるとブレにくいです。(1) メインのユーザー向けホスト——reddit.com、www.reddit.com、新 UI やモバイル Web で追加されるサブドメイン。(2) 短縮リンク——redd.it など、リダイレクト連鎖の途中で別出口に落ちるとタイムアウトに見えることがあります。(3) 静的アセット——redditstatic.com をはじめ、スクリプトやスタイル、フォント類。ここが遅いと「ページの骨格はあるのに操作できない」状態になります。(4) メディア・プレビュー——redditmedia.com や画像／動画サムネイル向けのホスト（環境やクライアント版で名称が増減します）。(5) API／GraphQL——gql.reddit.com など、フィード取得の背後で動くエンドポイント。アプリ版は Web よりここへの依存が強いことがあり、公式アプリだけ開かない 症状の切り分けで重要になります。

これらをすべて「とりあえず同じ PROXY グループ」へ押し込んでも動く場合もありますが、ノード品質や地域制限の都合で レイテンシと切断耐性 が要求と合わないと、結果としてスピナーが長引きます。コミュニティサイト向けに安定性を優先したポリシー（例：低ジッター優先の url-test グループ）を一つ決め、Reddit 関連の明示ルールはそのグループへまとめて寄せるのが扱いやすいです。固定リストの丸写しより、不足ドメインをログから足し込み、必要なら ルールプロバイダ で追従する方が長期運用に向きます。

ルール記述のたたき台（参考ホスト名）

サブドメインはプロダクト更新で変わり得るため、ここに挙げる名前は 出発点 として扱ってください。実際のプロファイルでは、利用中のクライアントの接続一覧と突き合わせて不足を補います。DOMAIN-SUFFIX,reddit.com で広く覆う方法もありますが、企業ポリシーや国内直結の要件がある環境では範囲が広すぎる場合があるため、ログで必要性を確認してからにします。

CAPTCHA 層：hCaptcha と reCAPTCHA をまとめて扱う

hCaptcha は hcaptcha.com 配下にスクリプトとアセット、検証 API がまとまっていることが多く、まず DOMAIN-SUFFIX,hcaptcha.com を同一の安定ポリシーへ寄せるのが素直です。環境によっては *.hcaptcha.com 以外の CDN 名がログに出ることもあるため、失敗時のホストをそのままルールに追記します。Google reCAPTCHA は www.google.com や www.gstatic.com、google.com、recaptcha.net など、既存の「Google 全般を DIRECT に落とす」ルールと衝突しやすい 点に注意が必要です。Reddit 本体だけプロキシへ送り、reCAPTCHA 関連だけ別経路に割れると、チャレンジが永遠に回るように見えることがあります。

対策の基本は 検証フローに関わるホストを Reddit 本体と同じ出口へ揃える ことです。ただし www.google.com を丸ごとプロキシへ寄せると、検索や他サービスまで意図せず同じ経路に乗る副作用が大きい場合があります。そのときは、接続ログで実際に出たパス（パスではなくドメイン／SNI がルールの対象）を確認し、可能ならより狭い条件（サブドメインやルールプロバイダの細分化）を検討します。いずれにせよ、広告ブロック系ルールセットが CAPTCHA ドメインを先に潰していないか も合わせて確認してください。ブロックと分流は別問題ですが、結果として同じ「回り続ける」UI になります。

ルール行の順序とルールセット（rule-providers）

rules は上から評価されるため、Reddit／CAPTCHA 向けの狭い DOMAIN／DOMAIN-SUFFIX を、巨大な GEOIP ルールやサードパーティの広域リストより前に置きます。さもないと、意図せず別のポリシーへ流れ、ブラウザでは問題なくてもアプリだけ失敗する、という切り分けが難しくなります。rule-providers から展開される行も同様で、挿入位置がズレると更新のたびに挙動が変わります。運用の型は ルール分流のベストプラクティス に沿って整理し、コメントで「なぜこの順か」を残しておくとチームでも迷いにくくなります。

次の例は概念図です。ポリシー名 REDDIT_STABLE は、利用中のサブスクリプションのグループ名に置き換えてください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Place Reddit + captcha domains before broad catch-all / block rules
rules:
  - DOMAIN-SUFFIX,reddit.com,REDDIT_STABLE
  - DOMAIN-SUFFIX,redd.it,REDDIT_STABLE
  - DOMAIN-SUFFIX,redditstatic.com,REDDIT_STABLE
  - DOMAIN-SUFFIX,redditmedia.com,REDDIT_STABLE
  - DOMAIN-SUFFIX,hcaptcha.com,REDDIT_STABLE
  - DOMAIN-SUFFIX,recaptcha.net,REDDIT_STABLE
  - DOMAIN-SUFFIX,google.com,REDDIT_STABLE
  - DOMAIN-SUFFIX,gstatic.com,REDDIT_STABLE
  - MATCH,PROXY_OR_DEFAULT

上例の google.com／gstatic.com を広く取ると副作用が大きいため、reCAPTCHA 実測で必要な範囲に絞る／別プロファイルに分けるなど、環境に合わせた調整が必須です。重要なのは、チャレンジと本体で出口の癖が食い違わない ことと、ブロック系ルールより手前で必要ホストを拾うことです。

システムプロキシと TUN：Web と公式アプリの取りこぼし

macOS／Windows／Android などで Clash を動かす場合、システムプロキシ方式と TUN 方式のどちらか（または併用）を選ぶことが多いです。ブラウザは OS のプロキシ設定を素直に読む一方、公式アプリは独自のネットワークスタックを持ち、システムプロキシを無視する パスが残ることがあります。その結果、Safari や Chrome ではタイムラインが出るのに、Reddit アプリだけ認証やフィード取得でスピナーが止まらない、という差が出ます。

切り分けは単純で、同じアカウントとネットワーク条件のまま システムプロキシのみ と TUN のみ を A/B します。TUN に切り替えて症状が消えるなら、カバレッジ不足を疑います。TUN は他製品の仮想アダプタや企業 VPN とルート優先度が衝突することもあるため、前提と典型は TUN の深掘り記事 を参照し、二重捕捉を避けてください。

サブスクリプション更新やルールプロバイダ取得が不安定なチェーンに乗ると、ルールが古いままになり「昨日まで動いていた」状態に陥ります。更新系は確実な DIRECT か低リスクの専用グループを残し、Reddit 閲覧トラフィックと混ぜない方が安全です。

DNS・fake-ip と「名前は返るのに転送が進まない」

fake-ip モードでは、アプリに返る IP が合成値であり、実際の名前解決とルーティング判断は Clash 側の DNS 設定と密接に結びつきます。DOMAIN-SUFFIX が薄いと、一見すぐに応答が返るのに TCP が進まず、タイムアウトに見えるパターンが出ます。Reddit 本体と CAPTCHA ドメインを明示ルールで覆い、nameserver-policy やフォールバックとルーティングを一致させると改善しやすいです。TLS や接続切断の読み方は 接続ログと TLS タイムアウト も参考にしてください。

複数の VPN／フィルタ／社内 DNS が同時に有効だと、同じラベルに別の答えが返り、アプリだけ到達不能なアドレスへ向くことがあります。一時的にクリーンな回線へ切り替えて比較し、「名前が悪い」のか「経路が悪い」のかを分けます。一般的な DNS の整理は FAQ も併せて参照してください。

既存のトレンド記事との棲み分け

当サイトには動画配信向け（例：Netflix／Disney+）や生成 AI ベンダー向け（ChatGPT、Gemini、Claude など）の分流記事がありますが、本稿の主役は Reddit 本体・静的資産・CAPTCHA というコミュニティ／ボット対策の名前空間です。手法（ドメインルール、ルールセット、TUN、DNS）は共通でも、対象ホストの集合は別物なので、記事を取り違えないようにしてください。開発者向け IDE（Windsurf など）の記事とは、依存するマーケットや API のホストが異なります。

⚠ コンプライアンス：法令、Reddit の利用規約、職場のセキュリティ方針を遵守してください。本稿は許可されたネットワークでの接続安定化の整理であり、未承認の迂回やポリシー回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash と Reddit を併用することが許可されているか確認する。
  2. 失敗時のホスト名を列挙し、Reddit 本体／静的／メディア／API／CAPTCHA のどの層か分類する。
  3. rules の順序と rule-providers の挿入位置を確認し、広域リストやブロック系が先に当たっていないか見る。
  4. システムプロキシのみ・TUN のみを A/B し、公式アプリの取りこぼしを潰す。
  5. DNS モードと fake-ip をルールと整合させ、接続ログで停滞段階を切り分ける。
  6. サブスクとルール更新がループせず成功する直列経路を残す。
  7. 別回線やモバイルテザリングで切り分け、ISP 側とサービス側障害を除外する。

各ステップの前後でログ行を残すと、設定の総入れ替えより早く収束します。

まとめ

Reddit の「ずっと読み込み」は、単一の帯域不足だけでは説明できないことが多く、本体・静的・メディア・API・CAPTCHA に層を分けて見ると対処が明確になります。Clash ではドメインルールとルールセットの順序で出口が決まるため、必要ホストを MATCH より手前に置き、システムプロキシと TUN のどちらが実トラフィックを覆っているかを一致させることが重要です。DNS／fake-ip を同じ設計言語で扱えば、見かけのタイムアウトの多くは観測可能なずれに還元できます。

プリセット任せより、接続ログにドメインと選択ポリシーが残る構成の方が、再現と改善のサイクルが回しやすいです。コミュニティ利用でも、長期運用では「自分の環境で実測したホスト名」をプロファイルに反映し続ける姿勢が効きます。

同種のツールと比べると、Clash 系はポリシー表現が明示的で、接続ログから握手・転送・切断の段階を追いやすいです。謎のワンタップ設定に振り回されるより、ルールが読めるクライアントの方が時間の節約になります。

→ 層別ルールが固まったら、Clash を無料ダウンロードし、同じ方針をブラウザと公式アプリの両方に載せてみてください。スピナーで失われる時間を、本来の閲覧や投稿に戻せます。