OpenWrtでClash運用：PCクライアントと共存するゲートウェイとDNS

まず決める：「誰がデフォルト経路を握るか」

同一 LAN 内で ルーター代理 と PC クライア を併用するとき、最初に決めるのは「インターネットへのデフォルト出口を、最終的にどこが代表するか」です。典型としては次の二系統があります。（A）ルーターが透明プロキシ／redirect／TProxy などで LAN からの通信を Clash に流し、各端末は従来どおりルーターを デフォルトゲートウェイ にする。（B）ルーターは素の NAT のみとし、プロキシが必要な PC だけが TUN やシステムプロキシでローカル Clash を有効にする。

（A）と（B）を「端末ごとに混在」させることは可能ですが、その場合は DHCP のオプション（DNS サーバ、オプションで配る静的ルートなど）と、手動設定した端末の取り違えが起きやすくなります。とくに「ルーター側 Clash は有効なのに、PC の Clash も TUN で丸ごと奪う」構成は、二重にプロキシが噛む・期待したポリシーと違う出口に出る、といった症状の温床です。運用方針を一文で書き留めてから DHCP と手動ホストを触ると、後からの切り分けが格段に楽になります。

ゲートウェイを二重にしない：DHCP と手動 IP の落とし穴

OpenWrt の lan インタフェースが配るデフォルト GW は、多くの場合そのルーター自身です。ここに対して、PC 側で「デフォルト GW を別マシン」にしたり、VPN クライアントがデフォルトルートを差し替えたりすると、LAN 内のプリンタや NAS、IoT セグメントへの戻り経路と期待がズレます。症状としては「ブラウザは開くが同一サブネットの機器に届かない」「特定アプリだけタイムアウト」などが出ます。

ルーター Clash を有効にする場合、原則は「LAN クライアントのデフォルト GW はルーターのまま」に置き、ルーター側の iptables／nft と Clash の受け口（redirect ポート、TProxy マークなど）が整合しているかを確認します。PC 側 Clash を併用するときは、TUN の「デフォルトルートを奪う」強さを下げる、システムプロキシのみにする、あるいはルーター側と「どちらか一方だけが最終出口」を担当する、と決め切るのが安全です。Windows の「インターネットに接続するためにプロキシサーバーを使用する」とルーター透明代理を同時に誤解して二重指定になるケースにも注意してください。

DHCP が配る DNS：ルーター自身か、Clash のリスナーか

多くの OpenClash 系セットアップでは、LAN の DNS としてルーター自身（例：192.168.1.1）を DHCP で配り、dnsmasq や同等の仕組みから Clash の DNS ポートへフォワードするパターンが取られます。このとき重要なのは「端末が実際にどの IP に問い合わせているか」です。PC だけ手動でパブリック DNS（8.8.8.8 等）を指定していると、Fake-IP やローカルドメイン向けの例外がルーター側の想定とズレ、分流ルールと名前解決結果が一致しません。

全端末をルーター DNS に揃えるのが一番わかりやすい一方、社内の独自リゾルバや分割 DNS を使う環境では、OpenWrt の dhcp option やドメインサフィックスごとの転送先を整理する必要があります。ルーター Clash の nameserver-policy や fake-ip-filter 相当の考え方は、デスクトップ単体のときと同じく、例外を先に設計した方が安定します。YAML の分流設計の骨格は ルール分流ガイド と合わせて読むと、ルーター用と PC 用で設定を二重管理しすぎずに済みます。

Fake-IP と LAN：「一部の機器だけおかしい」を疑う順序

ルーターで Fake-IP を使う構成では、LAN 端末が受け取る A レコードが擬似アドレスになります。ブラウザやアプリはそのアドレスへ接続し、実際の転送は Clash がドメインとルールから決めます。ここでトラブルが出やすいのが、ローカルドメイン（*.lan や社内サフィックス）、mDNS（.local）、および「解いた IP をそのまま信用して二次接続する」アプリです。症状は「特定サイトだけ白紙」「ストリーミングだけリージョンが合わない」「スマート家電だけ不安定」などに分かれます。

切り分けは、まず不通な端末の DNS サーバ設定を確認し、ルーター DNS に揃えたうえで再現するか見ます。続けて Clash 側のローカル向け例外（fake-ip-filter 相当、nameserver-policy、DIRECT ルール）がそのドメインを覆っているかをログで確認します。ルーターと PC の両方で Clash を動かしている場合、PC 側だけ別 DNS に向いていると「ルーターでは直ったのにこの PC だけダメ」が起きるため、端末ごとの設定表を作っておくと早いです。

PC 側 Clash を併用するときのモード選び

ルーターがすでに透明代理で Clash を通しているなら、PC では「ブラウザ拡張やアプリ単位のプロキシ」など、OS 全体を再び TUN で包まない選択肢が衝突しにくいです。どうしても PC 側でもフル TUN が必要な場合は、ルーター側の対象トラフィックを限定する（特定 VLAN だけ、ゲスト SSID だけルーター Clash など）か、PC 側で「システムプロキシのみ」「ルールモードでローカルは DIRECT」に寄せて二重処理を避けます。

macOS の「VPN」や別種のフィルタドライバ、Windows の他社 VPN と Clash TUN が競合すると、名前解決やルートテーブルが一時的に壊れたように見えることがあります。このときはルーター設定以前に、PC 単体で TUN をオフにして挙動が戻るかを確認すると原因の層が切れます。手順の詳細は TUN 関連の記事 を参照してください。

OpenWrt 側で押さえる設定ポイント（概念）

固有名詞付きの手順はファームウェアとパッージの版で変わるため、ここでは「どこを見るか」のチェックリストに留めます。WAN が PPPoE の場合、再接続時に DNS が上書きされないか。Firewall のゾーンで LAN→ルーター自身の DNS ポートが許可されているか。IPv6 が有効なら、IPv6 の DNS や RA（ルーターアドバタイズメント）が意図せずクライアントに別のリゾルバを教えていないか。ループバックや hairpin で同一 LAN 内のサーバ公開をしている場合、redirect ルールと衝突していないか。

OpenClash を使う場合、コアの稼働ポート、Redir-Host／Fake-IP の切替、iptables モードと nftables の相性、および「DNS ハイジャック」を有効にしたときの dnsmasq との住み分けを、変更のたびにメモしておくとロールバックが速くなります。変更は一項目ずつ入れ、都度 ping と HTTPS の両方で確認する習慣が有効です。

推奨の切り分け順序（短時間で効く並び）

1. 問題の端末で、デフォルト GW と DNS が何になっているか（DHCP か手動か）を確認する。
2. ルーター管理画面に同一 LAN から到達できるか。到達できなければ L2／GW より先を疑う。
3. ルーター Clash を一時停止し、症状が消えるかを見る。消えるならルーター側の redirect／DNS 周りに集中できる。
4. PC 側 Clash をオフにし、症状が消えるかを見る。ここで消えるなら PC の TUN／プロキシ競合が本命。
5. DNS のみパブリックに向けた対照実験をし、Fake-IP 絡みかどうかを切り分ける（本番運用値に戻すのを忘れずに）。
6. Clash ログで該当ドメインのポリシーと実接続先を追い、ルールと名前解決の食い違いを潰す。

この順序は「設定の正しさ」を議論する前に、どの層で壊れているかを機械的に狭めます。DNS だけの深掘りが必要になった段階で DNS モード記事 に移ると迷子になりにくいです。

構成別：よくあるつまずき早見

まとめ

OpenWrt で ルーター代理 を動かしつつ PC クライア を残すときの鍵は、デフォルトゲートウェイ と DHCP DNS の責任を一文で決め、二重の透明プロキシや二重の名前解決経路を作らないことです。Fake-IP を使うなら、LAN 全端末が同じ DNS ポリシーを見ているかを最初に確認し、例外ドメインはルール以前に DNS 側で整理します。切り分けはルーター／PC の Clash を順にオフして層を切ると、設定項目の海に沈みにくくなります。

デスクトップだけで完結させる場合でも、コアの挙動や YAML の考え方はルーター運用と共通です。手元の OS 用クライアントを揃えておくと、ルーター側をいじったあとも同じルール思想で戻りやすくなります。

ほかのチュートリアルは 技術コラム からどうぞ。