1 記事の位置づけ
Mihomo（旧 Clash Meta 系）が、プロバイダが発行する サブスクリプション（いわゆる 机场 系 購読 リンク）を扱うとき、多くのユーザーは proxy-providers や external-controller 越しの GUI から、HTTPS の URL を1本登録します。更新ボタンを押すと、コア内部の HTTP クライアントがその URL へ GET し、返却された YAML／Base64 等を パースして プロキシ 一覧に展開する、という流れです。ここで失敗する典型が HTTP 403 と、「ステータスは 200 だが中身が空 or 解釈不能で 0 ノード」の二系統です。
同じ悩みでも、Sub-Converter や mixin は「形式を変えたい・追記を残したい」層向けの話題です。一方、本稿の焦点はもっと手前で、拉取（取得）の HTTP 層、および本文が壊れていないかの層に限定します。設定ファイルの礎の置き方は、必要に応じて Linux 向けの Mihomo 導入と併せて参照してください。
2 症状の整理（ログと併記する）
まず UI 上の言い方を揃えます。403 はサーバまたは手前の CDN / WAF が「このリクエストは拒否」と明示したケースで、購読 の更新ログに 403 が残りやすいです。逆に 200 だが プロキシ が0件、は「HTTP は通ったが、本文が期待したフォーマットではない」「リダイレクト 先の本文だけが有効」など、ステータスだけ見て安心しないパターンが混ざります。メッセージに parse や invalid、empty といった語が出るなら、取得後の 解析 側の手掛かりです。
次に、登録した URL の種別を分けます。短縮 URL や帯域計測用の中継、トークン付きの長い1回きりリンク、ダッシュボードの「表示用 URL」と「API 用 URL」が別、といった違いは、後述の User-Agent 要件や リダイレクト 挙動に直結します。ブラウザのタブに貼ると平気でも、Mihomo からだと弾かれる、という比較は最強の手がかりです。
3 User-Agent が壁になる理由
多くの 机场 パネルやオブジェクトストレージの直リンクは、デフォルトの Clash / Mihomo クライアントが送る User-Agent 文字列を、セキュリティ上または誤防衛上、ブラウザ以外として扱います。結果として HTTP 403 や、代替の HTML エラーページが返ることがあります。対策の基本は、プロバイダ定義（YAML）または GUI が書き戻す同等の欄で、空でない user-agent を指定することです。よく使われるのは、一般的なブラウザに近い文字列、またはプロバイダのドキュメントで明示された値です。どちらにせよ、推測ではなく、発行元の案内を最優先してください。
headers に User-Agent を足す、Referer を同じ 机场 サイトに合わせる、といった手も、ホットリンク対策先では効く場合があります。ただし Referer の偽装は利用規約と矛盾しない範囲に留めることが前提です。GUI 利用者は、上級画面や設定ファイル直編集で、該当 proxy-providers ブロックに同様のキーがないか探すと切り分けが早いです。
4 リダイレクトと「直 URL」化
302 / 301 の連鎖
短縮 URL や計測用の入口は、1回目の応答で 301 や 302 を返し、最終的な https://…/…yaml へ飛ばす構成が多いです。クライアントが リダイレクト を十分に辿れない、途中で 403、あるいは Cookie や トークン を要求する中間 3xx の扱いで止まる、といった不整合が起こり得ます。切り分けの実務的な手は、ブラウザの開発者ツールで 最終的に成功している URL（ネットワーク欄の最後の1本）を控え、それを Mihomo 側にそのまま登録し直すことです。
0 ノードの典型
中間 URL が HTML のランディングページ（「クリックで続行」等）を返し、HTTP 200 でも中身が YAML ではない──この場合、パーサは黙って失敗し、プロキシ 0 件に見えます。逆に、最終 URL に差し替えると一気に直る、という体験は非常に多いです。URL に余分な 改行 や スペース が混ぎっていないかも、併せて確認してください。
5 TLS 証明書と端末時刻
取得先が 自前ドメイン かつ、証明書の被閲覧名（サブドメイン）と 実 URL のホスト名が食い違うと、TLS ハンドシェイク段階で失敗し、UI では「接続不可」「証明書エラー」に寄ることがあります。社内 ミドルボックス でルート CA を端末に入れていない環境では、同様の症状が出ます。対処の方向性は、正しい https:// ホスト名を使う、あるいはネットワーク側の MITM を解消する、です。
加えて、端末の システム時刻 が大きくずれていると、証明書の有効期間検証に失敗し、一見「謎の接続失敗」になります。特に仮想マシンや、長期スリープした Linux 箱で Mihomo を回している場合、時刻合わせ（systemd-timesyncd 等）を先に直す価値があります。これは 拉取 専用の話に見えて、HTTPS 全般の前提です。
6 本文の形式と文字コード
返却が ss:// や vmess:// 列挙の Base64 本文なのか、proxies: を含む YAML なのか、あるいは gzip 圧縮付き Content-Encoding なのかは、机场 ごとに違います。パーサが期待とズレると、やはり 0 ノード です。ここを疑うときは、取得結果を一時的に ローカルファイル へ落として中身の先頭数行を人間の目で確認し、文字コード が UTF-8 か、BOM や不可視文字で壊れていないか、を見るのが確実です。
一部の CDN は Accept-Encoding によって圧縮配信を切り替え、クライアントによっては想定外の組み合わせが出る、という辺境事例もゼロではありません。GUI で再現するなら、同じ 購読 を別のコアや別バージョンの同族アプリに取り込んで比較し、コア差で消えるなら、取得パスのバグ疑い、で切り分けが進みます。
7 ブラウザで開けるのに Mihomo だけダメな理由
ブラウザは Cookie・JavaScript・複雑なリダイレクト・Same-Site クッキー まで持ち合わせた「重い」クライアントです。一方 Mihomo の 購読 取得は、基本的に単純な HTTP GET の積み重ねに限られます。ダッシュボード上で表示される 購読 ボタンが、実はログイン セッション 前提の XHR だった、という罠に気づくと、公開用の生 URL ではなく、API 用 URL や、パネルが発行する Clash 専用リンクに差し替える必要が出ることがあります。これは「User-Agent だけ直せ」より手前の誤解であることも多いです。
8 ログの見方と次の手
購読 更新直後のログ行に、status=403、tls、redirect、empty body などの手掛かりが出る場合があります。UI がそれを出さないときは、External Controller + Yacd など、既存の可視化手段と、コアのログレベル上げ、を組み合わせます。併せて、同じ URL を curl -vI や、ブラウザ拡張の再現リクエストで叩き、レスポンスヘッダ だけ揃うか、を突き合わせると、どの段でズレるかがはっきりします。
最後の手段として、自前 Sub-Converter や信頼できる中継サーバを挟み、User-Agent と 最終取得先 をそこで固定する、という逃げ方も実務上は存在します。ただし、別コンポーネントを信頼する分、更新と秘密情報の扱いは慎重にしてください。
9 まとめ
Mihomo 購読拉取で詰まるとき、まず User-Agent と リダイレクト の仮説を外し、必要なら 直リンク 化します。次に TLS と端末 時刻、本文 の形式と 文字コード、そして ブラウザ専用 ではないかの確認、という順が再現性が高いです。HTTP 403 も 0 ノード も、見た目の症状は違っても、多くはこのチェーンのどこかに倒れます。
他の Clash 系 クライアント でも、取得まわりの心配事は同じ土俵です。デスクトップ版をまとめて試すなら、同じ YAML 思想で揃いやすい配布物から入るのが扱いやすく、本サイトのダウンロードで環境に合うパッケージを選ぶ形が、更新と導線の追跡の両面で無難です。GitHub の Release を直接追うより、まずは公式導線に寄せると、初回導入と再現の手間を減らしやすいです。
