なぜ macOS だけ「システム拡張」の話が出るのか

Apple はカーネル拡張の時代から段階的に System Extension（システム拡張） と Network Extension まわりの承認フローを厳格化してきました。Clash 系クライアントのなかには、仮想ネットワークや TUN 相当の転送を OS レベルで扱うために、インストール後に「開発元を信頼する」「拡張機能を有効にする」といった明示的なユーザー操作を求めるものがあります。

Windows の Wintun や Android の VPN 許可と似た「初回だけ手間がかかる」系の話ですが、macOS は設定アプリのどの画面にボタンが出るかがバージョンやクライアント実装で微妙に異なり、説明が追いつかないと「インストールは終わったのにプロキシが全然効かない」ように見えがちです。ここから先は、権限（拡張）と購読取得（HTTP）を分けて考えると迷子になりにくくなります。

症状：拡張機能がブロックされた／TUN をオンにできない

代表的な見え方は次のようなものです。文言はクライアントや macOS の言語設定で多少変わります。

  • 起動直後に「システム拡張がブロックされました」「開発元を確認してください」といったダイアログやバナーが出る。
  • TUN モードや「システムプロキシを有効化」まわりのトグルがグレーアウトする、またはオンにしてもすぐ戻る。
  • メニューバーアイコンは動くが、期待した仮想インタフェースが作られず、ログに権限・署名・拡張ロードに関するエラーが残る。

この段階では購読 URL が正しいかどうかより先に、OS がクライアントの拡張を許可しているかを確認するのが先です。拡張が止まったままだと、後続の DNS ハイジャックやルーティングも期待どおりに初期化されません。

対処：プライバシーとセキュリティで許可する（現実的な順序）

次の流れは、多くの環境で再現性が高い順に並べています。途中で「もう許可したはず」でも、再起動後に再度プロンプトが出るケースは珍しくありません。

  1. システム設定を開き、プライバシーとセキュリティ（または旧バージョンでは「セキュリティとプライバシー」）を開く。
  2. 画面下部付近に、ブロックされたシステムソフトウェアや拡張に関する許可ボタンが表示されていないか確認する。表示されていればタップして許可する。
  3. 同じ画面内で、開発元やフルディスクアクセスなど、クライアントが案内する追加権限があれば順に付与する（GUI によってはインストーラ側のチェックリストにリンクがある）。
  4. クライアントをいったん終了し、Mac を再起動してから再度 TUN／システムプロキシを試す。
注意：企業管理下の Mac では MDM ポリシーにより、ユーザー側の「許可」がそもそも表示されないことがあります。その場合は個人設定ではなくデバイス管理者への問い合わせが必要です。自己責任で SIP を無効化するなどの極端な手段は、トラブルの温床になるため推奨しません。

管理対象外の個人利用であれば、許可 → 再起動 → クライアントの再試行の三点セットを踏むだけで、見かけ上「壊れていた」TUN が突然動き出すことはよくあります。

Clash Verge macOS を含む GUI ごとの表記差

同じ Mihomo（Clash Meta）コアを同梱していても、メニュー名や「サービスモード」「管理者権限相当のヘルパー」の有無は GUI によって異なります。Clash Verge Rev の入門ガイドでは画面導線を広く押さえていますが、macOS だけで詰まるときは、まず公式ドキュメントやリリースノートに書かれた macOS 向け注意を優先し、次に OS の設定画面を照合するのが安全です。

用語のレイヤーとしては、「システムプロキシをオンにする」だけでは拾えないトラフィックを TUN で掬う、という Windows 記事で触れた構図と同型です。違うのは macOS が拡張ロードの承認 UI を挟む点です。拡張が通ったあとで初めて、Windows 版と同様にルートや DNS の話に進めます。DNS 漏洩防止ガイドと併読すると、TUN オン後の名前解決設計も整理しやすくなります。

別問題：購読（サブスクリプション）の更新だけが失敗する

拡張まわりがクリアできている、あるいはシステムプロキシだけで十分な段階でも、購読 URL の定期取得だけがタイムアウトや TLS エラーで止まることがあります。ここでは「クライアントが壊れた」より先に、HTTP クライアントとしての取得経路を疑うと早いです。

URL・認証・リダイレクト

コピペミス、トークン付き URL の期限切れ、短縮 URL のリダイレクト連鎖、Basic 認証の打ち間違いなどはどの OS でも起きます。ブラウザでは開けるのにクライアントだけ失敗するときは、User-Agent や Referer を要求する配信側の差も疑います。可能なら同じ URL を curl -v で叩き、ステータスコードと最終的に返るコンテンツ種別（本当に YAML／Base64 か）を確認してください。

TLS・中間証明書・プロキシ連鎖

社内プロキシやセキュリティ製品が HTTPS をスキャンする環境では、OS のキーチェーンにない独自 CA が挟まり、クライアントだけ証明書検証に失敗することがあります。また、まだ Clash 自体が動いていない状態で購読先だけプロキシ経由にすべきというチキンエッグも起こり得ます。対策としては、一時的に別回線（テザリング）で取得できるか試す、配信元が直リンクを用意しているか確認する、などが現実的です。

更新間隔とファイル肥大化

更新間隔を極端に短くしすぎるとレート制限に当たり、一見「ランダムに失敗」に見えます。ルールセットや Rule Provider を同時に大量取得している場合も、ディスクやメモリより先に同時接続やタイムアウトで落ちることがあります。高速化まわりの記事で触れている購読間隔の考え方も参照ください。

プロキシが効かないときの短い切り分け

購読は取れたがブラウザが直結したまま、という場合は次を順に見ます。

  • システムプロキシが実際にオンになっているか（ブラウザが「システム設定を使用」になっているか）。
  • TUN を使う構成なら、拡張とルートの初期化が完了しているか（前述の許可フローを再確認）。
  • ルールで意図せず DIRECT に落ちていないか──フローログのマッチ行を追う。

ログの読み方の骨格は ログ診断の記事に譲ります。macOS 特有の層を通過したあとは、コアの挙動は他 OS と大きく変わりません。

チェックリスト（初回設定でそのまま使える）

  • プライバシーとセキュリティに保留中の許可が残っていないか
  • 許可後に再起動したか
  • 購読 URL をブラウザと curl の両方で検証したか
  • TLS エラー時に別回線で再現するか
  • プロキシ未起動の状態で購読先だけプロキシ必須になっていないか
  • TUN 利用時は拡張ロード後に DNS／ルートを再確認したか

まとめ

macOS での Clash 初回セットアップは、システム拡張の承認フローを通すまでが一つの山であり、ここを飛ばすと TUN やシステム連携まわりがすべて不安定に見えます。別の山として、購読取得は素の HTTP クライアントとしての成否が支配的で、TLS・リダイレクト・プロキシ連鎖・レート制限のどれかに当たっているケースが多いです。二つを混ぜずに切り分けると、再インストールループに入らずに済みます。

コアのフィールド意味や全体像は ドキュメント が一次情報に近く、トピック横断の読み物は 技術ブログの一覧 から辿れます。安定したクライアントの入手と更新は、検証済みパッケージがまとまっている公式導線に寄せた方が、同梱ヘルパーや拡張の取りこぼしを減らしやすいです。→ macOS 向け Clash を無料ダウンロードし、拡張許可から購読までを一気通貫で試す