1. トポロジと前提
よくある構成は、ISP 直結の メインルータ（例：192.168.1.1）の下に、OpenWrt や汎用 Linux の サブルータ（例：192.168.1.2）を置き、LAN 端末の既定ゲートウェイだけを 192.168.1.2 に変えるパターンです。ここで重要なのは「サブルータの WAN 側がメインの LAN と同一セグメントにあるか」「サブルータ自身のデフォルトルートがメインルータを向いているか」という二点です。前者が崩れると ARP が届かず、後者が無いと Clash がトンネルを張っても戻りパケットが散逸します。
透過プロキシでは、端末はプロキシ設定を意識せず TCP／UDP を送出するため、カーネルの転送と netfilter の REDIRECT／TPROXY、あるいは TUN インタフェースによるキャプチャのどれかが必ず絡みます。OpenWrt では fw4 が nftables を生成し、手組み Linux では nft コマンドか iptables-nft 互換レイヤが混在しがちです。同じ番号のルールが二重に当たると「一部アプリだけ直結」のように見えるので、まず nft list ruleset と iptables-save の両方を眺め、どちらが実効かを決め打ちしてください。
2. LAN 端末のゲートウェイとマスク
「ゲートウェイを変えたのに挙動が変わらない」場合、端末が DHCP でメインルータから再取得している、あるいは静的ルートで特定プレフィックスだけ別出口へ逃げているケースが多いです。Windows なら route print、macOS／Linux なら ip route で default 行を確認し、本当にサブルータの LAN アドレスになっているかを見ます。IPv6 が有効なら RA（ルータ広告）でゲートウェイが上書きされ、IPv4 だけ手動でも通信が v6 優先でバイパスすることもあります。
サブネットマスクが広すぎると、同一 L2 上の別機器へ直接 ARP してしまいサブルータを経由しないフローが生まれます。セグメント設計を変えられない場合でも、少なくともテスト端末一つではマスクとゲートウェイを明示し、想定どおりサブルータのインタフェースにパケットが載るかを tcpdump -ni br-lan 等で確認すると迷いが減ります。
DNS だけメイン側のまま
ゲートウェイはサブルータでも、DNS がメインルータ（192.168.1.1）やキャリア DNS のままだと、ドメイン規則が効く前に解決がズレます。端末の「DNS サーバー」表示と、実際に飛んでいるクエリ先を分けて見ることが重要で、後述の DNS ハイジャックとセットで読んでください。
3. サブルータの転送と戻り経路
Linux では net.ipv4.ip_forward=1（必要なら IPv6 も）が無いと、たとえ Clash が起動していてもフォワード経路で黙殺されます。sysctl の実行時設定と永続化ファイルの両方を確認し、再起動後も有効かを検証します。サブルータが NAT していない「純粋ゲートウェイ」構成なら、メインルータ側に「192.168.x.0/24 → サブルータ」静的ルートが必要になるなど、戻りの対称性が要件になります。
よくある詰まりは、LAN→インターネットは通るが、戻りがメインルータのデフォルト経路に飲まれて非対称になるパターンです。サブルータで MASQUERADE を掛けているのに上流にもう一段 NAT があると、ポート競合や MTU 問題が表面化します。まずはサブルータ自身から curl -4 https://example.com が通るか、続けて LAN 端末から同様の検査をし、どのホップで止まるかを切り分けます。
sysctl net.ipv4.ip_forward
ip route show default
ip rule listip rule にポリシールーティングが増えていると、マーク付きパケットだけ別テーブルへ逃がす 透明プロキシ構成と衝突することがあります。Clash のドキュメントで推奨されるルートと、手動で足したルールの優先度を突き合わせてください。
4. nftables／iptables と NAT
nftables では table／chain の優先度とフック位置（prerouting／postrouting）が挙動を決めます。透明化で典型なのは、prerouting で TCP を Clash の redir ポートへ送り、postrouting で MASQUERADE する二段構成です。legacy iptables のルールが残っていると nft バックエンド経由で二重適用されたり、逆にヒットしないことがあるため、運用方針を一本化し、不要なチェーンはコメントアウトではなく削除または無効化して再現性を確保します。
nft list ruleset
iptables-save -cUDP（QUIC や一部ゲーム）を扱う場合、REDIRECT ではなく TPROXY や TUN モードが必要になる場面があります。ここを誤ると「ブラウザだけ遅い」「Google 系だけ繋がらない」などドメイン偏りが出ます。まずは問題の端末から dig と curl -v を分け、TCP と UDP のどちらで詰まっているかをログと併せて見ます。
5. TUN と redirect／tproxy
TUN モードはルートを引き、プロセス境界を越えてトラフィックを集約しやすい一方、カーネルや systemd ユニットの起動順、他 VPN クライアントとの競合に弱いです。サブルータでは「Clash だけがルートを握る」状態を作れるかが鍵で、競合がある場合はまず TUN を外し、透過プロキシ専用の redirect／tproxy だけで再現する実験が有効です。
Windows 向けにルートと WFP を整理した TUN トラブルシュートは OS は異なりますが、「誰がルートを所有しているか」という観点では参考になります。Linux ゲートウェイでは ip route get の出力が期待どおり TUN デバイスを経由するかを必ず確認してください。
プロキシポートのバインド
redir／tproxy 先のポートが 127.0.0.1 のみで待っていると、フォワードされたフローが届きません。ゲートウェイ運用では 0.0.0.0 または LAN インタフェースへのバインドと、allow-lan 相当の設定を揃えます。ここは LAN 共有の Windows 11 の mixed-port 記事と同型の論点です。
6. DNS ハイジャックと漏れ
DNS ハイジャックとは、外向き UDP／TCP 53 をサブルータ上のローカルリゾルバ（多くの場合 Clash の DNS モジュール）へ転送し、ルールと同じ視点で名前解決させる手法です。DoT／DoH へ直行する端末や、Android の「プライベート DNS」、ブラウザ内蔵の Secure DNS を無効化しない限り、iptables／nft の 53 キャプチャだけでは抜けます。
fake-ip を使う構成では、解決結果と実接続先のズレで「一部サイトだけ証明書エラー」が出ます。fake-ip と DNS の切り分け記事と役割が重なるため、ゲートウェイで集約したあとに端末側の DoH が残っていないかを必ず確認してください。運用上は「まず redir-host で挙動を固定し、慣れたら fake-ip に戻す」ほうが切り分けコストが下がることが多いです。
dig @192.168.1.2 example.com +short
dig @1.1.1.1 example.com +short7. 症状と典型原因
| 症状 | よくある原因 | 確認コマンド／観点 |
|---|---|---|
| 端末からサブルータへ ping できるが HTTP が出ない | NAT または redir チェーン欠落 | nft list ruleset、Clash ログの接続先ポート |
| 海外サイトだけ直結のように遅い | DNS がキャリア側のまま | dig、端末の DoH／プライベート DNS |
| 数分おきに途切れる | IPv6 がバイパス、または MTU／MSS | ip -6 route、PPPoE 下での MSS 調整 |
| サブルータ単体は速いが LAN 端末は不可 | 戻り経路または rp_filter | sysctl net.ipv4.conf.all.rp_filter、上流静的ルート |
表のどれにも当てはまらないときは、まずサブルータの物理ポートとブリッジ設定（LAN／WAN の誤配線）を疑い、次に Clash のログレベルを上げて実フローがどの outbound に振られたかを追跡します。ルールより前に「パケットがコアに届いていない」段階で消耗しないことが、ゲートウェイ運用では最も大きな工数削減になります。
8. まとめ
サブルータで Clash を動かし、LAN 端末を透過プロキシへ乗せるときは、YAML 以前に「ゲートウェイとマスク」「カーネル転送と戻り経路」「nftables と legacy iptables の実効ルール」「TUN と redirect／tproxy の役割分担」「DNS ハイジャックと DoH 漏れ」の順に潰すと再現性が出ます。単体クライアントの記事では触れきれないレイヤですが、一度この順序をテンプレ化しておくと、次回以降の増築やファームウェア更新でも迷子になりにくくなります。
デスクトップで挙動を試したうえでゲートウェイへ広げる場合、各 OS 向けビルドは ダウンロードページから揃えると、ドキュメント上の機能差と実機のギャップを小さくできます。オープンソースの参照や Issue 追跡は各プロジェクトの公式情報を使いつつ、日々のインストール導線はサイト側に寄せると運用が安定します。