FlClashで特定のWebサイトだけ開けない、アプリの接続が不安定になる、ノードは正常なのに名前解決でエラーが出る――こうした問題では、DNSの設定が原因になっていることがあります。FlClashはMihomoをベースにしたプロキシクライアントで、DNS、ルール分流、TUN、Fake-IPなどを利用できます。ただし、DNSは「速いサーバーに変えればすべて解決する」という単純な設定ではありません。名前解決をどこで行うのか、どのDNSを使うのか、プロキシノードの名前解決をどう処理するのかによって結果が変わります。この記事では、FlClashのDNS設定を初めて調整する人にも分かるよう、基本項目からFake-IP、TUN、接続トラブルの切り分けまで順番に整理します。

1.FlClashのDNS設定を理解する前に、名前解決の仕組みを知る

DNSは、ドメイン名とIPアドレスを結び付ける仕組みです。

ブラウザで「example.com」と入力したとき、コンピューターはその文字列をそのまま通信先として使うわけではありません。まずDNSへ問い合わせを行い、対応するIPアドレスを取得します。この処理が「名前解決」です。

つまり、Webサイトへ接続するまでには、大まかに次のような段階があります。

ドメイン名を入力する → DNSで名前解決する → IPアドレスを取得する → 通信先へ接続する

この途中でDNSが正常に機能しなければ、プロキシノードそのものに問題がなくてもWebサイトを開けないことがあります。

FlClashでは、Mihomoが提供するDNS機能を利用できます。Mihomoの現在のDNS仕様には、nameserverfallbacknameserver-policyproxy-server-nameserverdirect-nameserverなど複数の項目があります。

設定項目が多いため、初めて見ると複雑に感じるかもしれません。

しかし、すべてを理解する必要はありません。

普段のWeb閲覧が目的なら、まず「通常のドメインをどのDNSで解決するか」を理解すれば十分です。そのうえで、特定のサイトだけ接続できない、TUNを使うと通信できない、LAN内の機器が見えなくなる、といった問題が出てきたときに追加設定を検討します。

この順番を守ることが、FlClashのDNS設定を必要以上に複雑にしないポイントです。

2.FlClashで確認したいDNSの基本項目

FlClashのDNS設定を調整するとき、最初に見るべき項目はそれほど多くありません。

特に重要なのがenablenameserverdefault-nameserverenhanced-modeです。

enableはMihomoのDNS機能を使用するかどうかを指定します。無効にするとシステム側のDNS解決が使われます。Mihomoの公式ドキュメントでも、この項目を無効にした場合はシステムDNSが利用されると説明されています。

nameserverは、通常のドメイン名を解決するためのDNSサーバーです。

ここには一般的なDNSサーバーのIPアドレスだけでなく、DoHやDoTなどの方式を指定することもできます。

DoHは「DNS over HTTPS」の略で、DNS問い合わせをHTTPS経由で行う方式です。DNS通信を通常のUDP/TCPだけで処理する方法とは異なり、暗号化されたHTTPS通信として扱える点が特徴です。

ただし、DoHを使ったから必ず速くなるわけではありません。

DNSサーバーまでのネットワーク距離、通信経路、サーバー側の応答速度によって結果は変わります。DNSを変更した直後にWebページの表示が改善したとしても、それは「インターネット回線そのものが高速化した」という意味ではありません。

一方、default-nameserverは少し役割が違います。

MihomoではDNSサーバー自体がドメイン名で指定されている場合、そのDNSサーバーの名前を解決するためにdefault-nameserverが使われます。公式仕様でも、通常のnameserverとは区別されています。

この違いを知っておくと、「DNSを設定したのにDNSへ接続できない」という一見矛盾した状態も理解しやすくなります。

3.Fake-IPとredir-hostは何が違うのか

FlClashのDNS設定で特に混乱しやすいのがenhanced-modeです。

Mihomoでは主にfake-ipredir-hostという2つのDNS処理方式があります。現在のMihomoドキュメントでは、デフォルト値はredir-hostとされています。

redir-hostは比較的分かりやすい方式です。

DNS問い合わせによって取得した実際のIPアドレスを使って通信します。一般的なDNSの動きに近いため、特殊なアプリやネットワーク機器との互換性を考える場合にも理解しやすいでしょう。

一方のfake-ipでは、DNS問い合わせに対して実際のサーバーIPではなく、Mihomoが管理する仮想的なIPアドレスを返します。

たとえばMihomoの設定では、198.18.0.1/16のようなアドレス範囲をFake-IP用に利用できます。Mihomoの仕様でもfake-ip-rangeはFake-IPのアドレス範囲を指定する項目として定義されています。

Fake-IPのメリットは、ドメイン情報を保持しながらルールによる通信制御を行いやすいことです。

特にTUNを利用して複数のアプリケーション通信をまとめて処理する環境では、Fake-IPが便利な場面があります。

ただし、すべてのアプリケーションと相性が良いわけではありません。

たとえば、LAN内の機器、特殊なネットワークプロトコル、IPアドレスを直接扱うアプリなどでは、Fake-IPによって期待した動作をしない場合があります。

このため、「FlClashではFake-IPを使うべき」と決めつける必要はありません。

ブラウザ中心の利用で問題がないなら、その状態を維持するほうが合理的です。特定のアプリだけ接続できない場合に、Fake-IPとその例外設定を疑うという順番で十分です。

4.FlClashのDNS設定で接続トラブルを切り分ける

DNS設定を変更したあとに接続トラブルが起きた場合、重要なのは複数の設定を同時に変更しないことです。

たとえば、DNSサーバー、Fake-IP、TUN、ルール設定を一度に変更すると、問題が解消しても何が原因だったのか分からなくなります。

まず、通常のDNS環境で対象サイトが開くか確認します。

OS側では正常に開くのにFlClashを有効にすると開かないのであれば、FlClashのDNS、ルール、プロキシノードなどを順番に確認します。

逆に、FlClashを停止しても開かないのであれば、DNSだけを調べても意味がありません。回線やWebサイト側、OS側のネットワーク環境など、別の原因を確認する必要があります。

特定のサイトだけ開かない場合

特定のドメインだけ接続できない場合は、DNSの応答そのものを疑います。

特に、国内サービスと海外サービスで結果が大きく異なる場合は、DNSサーバーによる応答やnameserver-policyfallbackの設定が関係している可能性があります。

Mihomoのnameserver-policyでは、特定のドメインやルールセットに対して使用するDNSを指定できます。公式仕様では、通常のnameserverfallbackより優先してドメインごとの名前解決先を指定できる仕組みになっています。

ただし、最初から複雑なポリシーを作る必要はありません。

特定のサービスだけ問題があるときに、そのドメインだけ別のDNSで解決する必要があるかを検討すれば十分です。

ノードだけ接続できない場合

Webサイトは開けるのに、特定のプロキシノードだけ接続できないケースもあります。

ここでは通常のnameserverだけを確認しても原因が見つからないことがあります。

Mihomoにはproxy-server-nameserverという設定があり、プロキシノードのドメイン名を解決するためのDNSとして利用できます。公式仕様でも、一般的なドメイン解決とプロキシサーバーの名前解決を分けて扱える項目として説明されています。

たとえばノードの接続先がドメイン名で指定されている場合、そのドメインが正常に解決できなければ、ノード自体が利用できません。

「WebサイトのDNSは正常なのに、ノードだけ失敗する」という場合には、この部分を確認する価値があります。

5.TUNを使う場合にDNS設定で注意したいこと

FlClashをブラウザだけで使うのであれば、TUNを必ず有効にする必要はありません。

しかし、アプリケーションによってはOSのシステムプロキシを利用しないものがあります。そのような通信までFlClashで処理したい場合、TUNが役立ちます。

TUNは仮想ネットワークインターフェースを利用して、より広い範囲の通信をFlClash側へ取り込む仕組みです。

その一方で、TUNを有効にするとDNSとの関係も複雑になります。

Mihomoではdns-hijackを利用してDNS通信を捕捉する構成が可能です。たとえば公式の設定例では、any:53などを指定してDNS通信をMihomo側で処理する構成が示されています。

この仕組みがうまく動けば、アプリケーション側が独自に使用するDNSをFlClash側で処理しやすくなります。

しかし、TUNをオンにした途端に一部のアプリが通信できなくなった場合は、DNSサーバーを変更する前に、まずTUNをオフにして比較するほうがよいでしょう。

FlClashのコア実装でも、TUN起動時にDNS情報を含む設定が渡される構造になっており、DNSとTUNが完全に独立した機能ではないことが分かります。

実際のトラブルシューティングでは、

TUNオフ → 接続確認 → TUNオン → 再確認

という単純な比較がかなり役立ちます。

TUNを無効にすると正常で、有効にすると失敗するなら、DNSサーバーそのものだけではなく、DNSハイジャック、ルーティング、Fake-IP、OS側のネットワーク設定などを疑うべきです。

6.DNS設定を複雑にしすぎないことも重要

FlClashのDNS機能は細かく調整できます。

nameserverで通常のDNSを指定し、必要ならfallbackを追加する。特定のドメインだけ別のDNSで処理したいならnameserver-policyを使う。プロキシノードの名前解決で問題があればproxy-server-nameserverを確認する。この程度の順番で考えると、設定がかなり整理されます。

fake-ip-filterも便利な機能です。

Fake-IPを適用したくないドメインを指定できるため、LANや特定のアプリケーションでFake-IPとの互換性に問題がある場合に利用できます。Mihomoではドメインワイルドカードやルールセットなどを使ったフィルタリングにも対応しています。

ただし、例外を増やしすぎると設定そのものが分かりにくくなります。

「接続できないから、とりあえずDNSを追加する」「アプリが動かないから、とりあえずFake-IPから除外する」という対応を繰り返すと、最終的にどの通信がどこを経由しているのか把握できなくなります。

DNS設定では、少ない変更で原因を特定することが大切です。

たとえば、ブラウザでは正常、特定のアプリだけ失敗するなら、まずそのアプリとFake-IPの相性を疑う。すべての通信が失敗するなら、DNSそのものやTUN、プロキシノードを確認する。LAN機器だけ見えないなら、ローカルドメインやFake-IPの除外を確認する。

このように症状から原因候補を絞るほうが、設定項目を片っ端から変更するより効率的です。

7.安定したFlClash環境を作るためのDNS設定

DNSは、普段は意識することの少ない機能です。

しかし、Webサイトを開く、アプリへ接続する、プロキシノードへ接続するという一連の処理の入口にあるため、問題が起きると「インターネットが使えない」という大きな症状として現れます。

だからこそ、FlClashのDNS設定では「最速のDNSを探す」より、「自分の環境で安定して名前解決できる構成を作る」ことを優先したほうがよいでしょう。

まず基本のnameserverを設定し、通常のWebサイトが問題なく開くことを確認します。次に必要があればfallbacknameserver-policyを追加します。Fake-IPを使う場合は、LANや特定アプリとの互換性を確認し、問題がある場合だけfake-ip-filterを利用します。TUNを使う場合は、DNSハイジャックやルーティングまで含めて動作を確認します。

この手順なら、DNSに詳しくない人でも設定を一つずつ確認できます。

そして何より、DNSを変更しても問題が解決しない場合には、DNS以外の原因へ視点を移すことが重要です。プロキシノードの障害、ルールによる誤った分流、TUNのルーティング、IPv6、OS側のネットワーク設定など、接続には複数の層があります。

FlClashをこれから使い始める場合は、FlClashの基本機能を確認したうえで、まず標準的なDNS設定から試すのが無難です。より細かなMihomoのDNS仕様やTUNとの関係を確認したい場合は、FlClashの関連情報も参考になります。大切なのは設定項目を増やすことではなく、「どこで名前解決しているのか」「どの通信がプロキシを通るのか」「問題がDNSなのか、それ以外なのか」を把握することです。その3点が分かれば、DNSトラブルの多くは落ち着いて切り分けられます。