📖 チュートリアル ⏱ 約19分で読めます

Linux で Clash／Mihomo 導入後にページが開けない：systemd-resolved・resolv.conf・DNS モードの段階チェック（2026）

Linux のデスクトップで Clash または Mihomo 互換クライアントを入れた直後から、ブラウザだけタイムアウトする・一部ドメインだけ開けない・国内サイトと海外サイトで挙動が真逆になる、といった名前解決まわりの不調はよくある報告です。多くの場合、カーネルやプロキシそのものより先に systemd-resolved や /etc/resolv.conf、クライアント側の DNS モード（Fake-IP／redir-host）、UDP 53 番のリスン競合のどれかが噛み合っていません。本稿は「コマンドと画面のどこを見ればよいか」を順番に固定し、自分の環境に当てはめて切り分けできるようにまとめた実務向けチェックリストです。GEOIP や「中国大陸を迂回」系のルール整理は 別稿 で扱い、ここでは stub リゾルバと Clash の DNS スタックに焦点を絞ります。

症状の整理：プロキシ以前に DNS が崩れているサイン

次のようなパターンは、TCP 接続より前のDNS、もしくはアプリが参照しているリゾルバの指し先を疑う目安になります。ping は通るのに HTTPS だけ失敗する、特定の TLD だけ遅い、Clash を止めると一瞬だけ直るがすぐ再発する、などです。

Linux では glibc のスタブリゾルバが 127.0.0.53 に問い合わせ、背後で systemd-resolved がキャッシュやフォワーディングを担う構成が一般的です。この「OS 標準の DNS パイプ」と、Clash が提供する「アプリから見える DNS（listen や redir）」が二重化すると、Fake-IP で返した仮想 IP を OS の別経路が解釈できず、ブラウザだけ異常になることがあります。

ステップ 1：いま誰が nameserver か（resolv.conf と resolvectl）

まず /etc/resolv.conf を開き、nameserver が 127.0.0.53 になっているか確認します。Ubuntu や Fedora 系の多くで、このファイルはシンボリックリンクで systemd-resolved 管理下に置かれます。手元で実体を追うには次のようにします。

ls -l /etc/resolv.conf
resolvectl status
# Legacy alias on some distros:
systemd-resolve --status

resolvectl では、リンクごとの DNS サーバ一覧と、どのインタフェースの設定が効いているかが分かります。VPN クライアントや Docker、別のプロキシと同時起動していると、ここに「想定外の upstream」が混ざり、Clash 側の仮想 DNS と食い違うことがあります。

💡 ヒント /etc/resolv.conf を手編集しても、NetworkManager や resolved が上書きする構成では次の再起動で元に戻ります。恒久対応は「Clash の DNS 設計を OS のスタブと整合させる」か、「クライアントの TUN／システムプロキシモードに合わせて OS 側の DNS を切り替える」かのどちらかに寄せるのが安全です。

ステップ 2：UDP／TCP の 53 番を誰が掴んでいるか

Clash Meta 系では、設定によってローカルで DNS を listen します。既に systemd-resolved が 127.0.0.53:53 を使用している環境で、Clash も同じアドレスにバインドしようとすると起動失敗やサイレントなフォールバックが起き、結果として「一部だけ解決できない」状態に見えることがあります。

次のコマンドで、ポート53 の所有者を把握してください（ディストリビューションによりパッケージ名は異なります）。

sudo ss -lunp | grep ':53'
# or
sudo lsof -iUDP:53 -iTCP:53

systemd-resolve または resolved が既に listen している場合、Clash 側では 別ポート で DNS を受け、OS のフォワーディング先をそこに向ける、あるいは クライアントの「システム DNS ハイジャック」機能に任せて resolved と役割分担する、といった整理が必要です。無理に二重 listen しないことが安定の近道です。

ステップ 3：Fake-IP と redir-host、どちらを選ぶか

Fake-IP は、ルール評価を早めるために一時的な仮想アドレスを返すモードです。一方 redir-host（実 IP を返す系）は、アプリや証明書ピンニングとの相性が素直な場面があります。Linux デスクトップで「ブラウザは開くがターミナルの curl だけおかしい」「逆にターミナルは正常でブラウザだけダメ」といった経路の分裂は、Fake-IP と OS リゾルバの組み合わせが原因であることが多いです。

切り分けとしては、一時的に redir-host 相当の設定へ寄せて挙動が揃うかを見ます。揃うなら、ルール順・nameserver-policy・fake-ip-filter（対象ドメインを Fake-IP から外す）のどれかで微調整する方針になります。詳細な挙動の背景は Clash Meta／Mihomo の sniffing・DNS 関連稿 と併読すると理解が速いです。

ステップ 4：TUN モードと「システム全体のデフォルトルート」

TUN を有効にすると、デフォルトゲートウェイや DNS の取り方が変わります。クライアントが「OS の DNS を上書きする」タイプの実装の場合、systemd-resolved のスタブと二重に上書きがかかり、逆にループやタイムアウトを招くことがあります。症状が TUN オン限定なら、一度システムプロキシのみに落として DNS が安定するかを比較してください。

仕組みの深掘りは TUN モード解説 に譲りますが、Linux では「権限」「カーネルモジュール」「他 VPN との競合」をセットで疑うのが定石です。

ステップ 5：DoH／DoT upstream とキャッシュの整合

Clash 側で DoH を upstream にしている場合、systemd-resolved も別の経路でキャッシュしていると、短時間だけ古い結果が残ることがあります。切り分けでは resolvectl flush-caches（利用可能な環境）や、Clash の DNS ログを併読して「どのサーバに問い合わせたか」を一致させます。

企業ネットワークでは透明プロキシが DNS を書き換えるため、自宅と同じ YAML でも解決結果が変わります。環境が変わったタイミングだけ不調が出る場合は、ルールより先に upstream の到達性 を疑ってください。

ステップ 6：アプリごとの「参照しているリゾルバ」差

Chrome 系は OS の設定を使いますが、一部のコンテナ／Snap／Flatpak は名前空間内に独自の resolv.conf を持ちます。WSL や Docker ホストとゲストで食い違う典型は WSL2 と Windows ホストの Clash 共有稿 で扱っている通りで、Linux 単体でも「ホストは resolved、コンテナは別ファイル」という二重構造は起こり得ます。

症状が特定アプリだけに閉じるときは、そのプロセスのマウント名前空間内の /etc/resolv.conf を確認する価値があります。

チェックリスト（そのまま順に試せる）

  1. 1

    OS の nameserver

    resolvectl status と /etc/resolv.conf を見て、127.0.0.53 経由か、直の ISP DNS かを把握する。

  2. 2

    ポート 53 の競合

    ss または lsof で Clash と resolved の二重 listen がないか確認する。

  3. 3

    Fake-IP の切り分け

    一時的に redir-host 側へ寄せ、症状が消えるか見る。fake-ip-filter で問題ドメインを除外する案を検討する。

  4. 4

    TUN の有無

    TUN オン／オフで DNS 挙動が変わるなら、ルートとリゾルバの上書き順をクライアントのドキュメントに沿って整理する。

  5. 5

    他 VPN・Docker との併用

    同時常駐をやめて単体で再現するか確認し、競合を切る。

よくある質問

systemd-resolved を止めてよいか

ディストリビューションの標準構成では、resolved を無効化すると NetworkManager や他サービスとの整合が崩れることがあります。止めるより、Clash の DNS 設計を resolved と両立できる形に寄せる方が安全なことが多いです。どうしても止める場合は、公式ドキュメントとサポートコミュニティの注意事項を確認してください。

なぜ「国内だけ遅い／海外だけ開かない」が出るのか

ルールで出口が分岐しているのに DNS だけが片側に固定されていると、IP は A 地域、実トラフィックは B ノード、といったジオロケーションの不一致が起きます。DNS の upstream をノード側に合わせる、あるいは対象ドメインの解決経路をルールと同じグループに載せる、といった調整が必要です。国内向けルールの棚卸しは 国内サイトと GEOIP CN のチェックリスト が参考になります。

CLI クライアントだけ使う場合も同じか

GUI が無くても、listen ポート・Fake-IP・OS の resolv.conf の関係は同じです。逆に、デスクトップ環境の「プロキシ自動設定」やブラウザ拡張が別経路を指していると、症状が複雑に見えます。

まとめ

Linux で Clash／Mihomo を動かしたあとの「ページが開かない」系トラブルは、まず systemd-resolved と /etc/resolv.conf で OS がどこに問い合わせているかを固定し、続けて ポート53 の競合と Fake-IP の有無を確認するのが効率的です。stub リゾルバ とクライアントの DNS スタックが二重になると、見た目は「プロキシのせい」に見えても実体は名前解決の取り合いであることが多いです。

ディストリビューション別の初回導入は Ubuntu 24.04 の Clash Verge 稿 や Arch Linux 向け稿 と役割分担できます。クライアントの入手とバージョンの揃え方は 本サイトのダウンロードページ を第一参照にすると、記事との対応も追いやすくなります。ソースや Issue は GitHub でも確認できますが、パッケージの主入口は本站に揃える運用がおすすめです。

用途ごとに出口と DNS を揃えられる点では、常時フルトンネル型の汎用 VPN より Clash の方がトラブル時の切り分けがしやすい場面もあります。→ Clash を無料ダウンロードし、Linux 上の DNS とルールを試す