tun:
  enable: true
  stack: mixed
  dns-hijack:
    - "any:53"
    - "tcp://any:53"
  auto-route: true
  strict-route: true
  auto-redirect: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - geosite:cn
    - geosite:category-ads-all
```text

### 2.2 TUN 模式详解

`auto-route: true` + `strict-route: true` 使 Mihomo 在启动时自动添加：
- **ip rule**（策略路由规则）
- **nftables**（`table inet mihomo`，prerouting + output 链）

两层拦截覆盖不同的协议和路径。

---

## 3. 拦截机制详解

### 3.1 nftables 规则集

```nft
table inet mihomo {
    set inet4_local_address_set {
        type ipv4_addr
        flags interval
        elements = { 127.0.0.0/8, 198.18.0.0/30 }
    }

    chain output {
        type nat hook output priority mangle; policy accept;
        oifname "Meta" meta nfproto ipv4 meta l4proto tcp
            counter redirect to :46569 return
    }

    chain prerouting {
        type nat hook prerouting priority dstnat + 1; policy accept;

        # 从 TUN 回来的包跳过（防循环）
        iifname "Meta" counter return

        # 本地 fake-ip 源发出的 DNS 查询 → DNAT 到 TUN 设备
        ip saddr @inet4_local_address_set meta l4proto { tcp, udp } th dport 53
            counter dnat ip to 198.18.0.2

        # 目标为本地地址的包跳过
        ip daddr @inet4_local_address_set counter return

        # MPTCP 选项丢弃
        tcp option mptcp exists counter drop

        # IPv6 拒绝
        meta nfproto ipv6 counter reject with icmpv6 no-route

        # ★ 核心规则：所有 IPv4 TCP → redirect 到透明代理端口 :46569
        meta nfproto ipv4 meta l4proto tcp
            counter redirect to :46569 return
    }
}
```text

### 3.2 Docker 相关 nftables 表

```nft
# 由 iptables-nft 管理，非 Mihomo 创建

table ip nat {
    chain PREROUTING { type nat hook prerouting priority dstnat; ... jump DOCKER }
    chain OUTPUT     { type nat hook output priority dstnat; ... jump DOCKER }
    chain POSTROUTING {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 172.17.0.0/16 oifname != "docker0"   MASQUERADE
        ip saddr 172.18.0.0/16 oifname != "br-700ced5fc520" MASQUERADE
    }
}

table ip filter {
    chain FORWARD { type filter hook forward priority filter; policy drop;
        jump DOCKER-USER
        jump DOCKER-FORWARD
    }
    chain DOCKER-FORWARD {
        jump DOCKER-CT
        jump DOCKER-INTERNAL
        jump DOCKER-BRIDGE
        iifname "br-700ced5fc520" accept
        iifname "docker0" accept
    }
}

table ip raw {
    chain PREROUTING {
        type filter hook prerouting priority raw; policy accept;
        ip daddr 172.18.0.2 iifname != "br-700ced5fc520" drop
        ip daddr 127.0.0.1 iifname != "lo" tcp dport 8090 drop
    }
}
```text

### 3.3 ip rule（策略路由）

### 3.4 路由表 2022

### 3.5 路由表 main（摘要）

---

## 4. 流量路径分析

### 4.1 本机程序发出的 TCP 流量

**场景：** `firefox` 等本地进程访问 `https://www.google.com:443`（IP: 142.250.80.68）

**关键点：**
- 路由决策决定了 oif = Meta，但包并未实际到达 TUN 设备
- OUTPUT hook 在路由决策之后执行，利用了已知的 `oifname`
- redirect 到 `:46569` 后重新路由为本地投递

---

### 4.2 本机程序发出的 ICMP/UDP 流量

**场景：** `ping 1.1.1.1`（ICMP echo）

**关键点：**
- ICMP 和 UDP 不触发 nftables OUTPUT 的 `tcp redirect`，实际到达 TUN 设备
- TUN 栈直接 NAT 转发，不经过核心引擎的规则匹配
- 日志中表现为 `write ICMPv4 echo request` / `read ICMPv4 echo reply`，无 `[TCP]` 条目

---

### 4.3 Docker 容器发出的 TCP 流量

**场景：** `docker exec axonhub wget http://1.1.1.1`

**关键点：**
- **容器源 IP（172.18.0.2）完整保留**，未经 SNAT
- 原因：`redirect` 在 `prerouting`（路由决策前）发生，将目标改为 `127.0.0.1`
- 重新路由判定为本地投递，不经过 `POSTROUTING`（Docker SNAT 在 POSTROUTING）
- `ip rule 9002` 也**不参与**，因为包在 nftables 阶段已被截获

**实测验证：**

```bash
# nftables prerouting 计数器
# 容器 wget 前：counter packets 29 bytes 1740
# 容器 wget 后：counter packets 32 bytes 1920  ← 增量 3（SYN+请求+ACK）

# Mihomo 日志
[TCP] 172.18.0.2:56690 --> 1.1.1.1:443 match Match using SELECT[🇺🇸US-DMIT]
                           ↑ 容器原始 IP，未 SNAT
```text

---

### 4.4 Docker 容器发出的 ICMP/UDP 流量

**场景：** `docker exec axonhub ping 1.1.1.1`

**实测验证：**

```bash
# 容器 ping 1.1.1.1 → 192ms（经代理转发的典型延迟）
# 容器 ping 192.168.1.1 → 1.2ms（直连延迟）

# Mihomo debug 日志
write ICMPv4 echo request from 198.18.0.1 to 1.1.1.1 id 19022 seq 166
read  ICMPv4 echo reply   from 1.1.1.1 to 198.18.0.1 id 19022 seq 166
# 注意 src 是 198.18.0.1（TUN 接口），不是 172.18.0.2（容器源 IP）
# 且无 [TCP] 规则匹配记录
```text

**TCP vs ICMP 路径差异总结：**

| 维度 | 容器 TCP | 容器 ICMP/UDP |
|------|---------|--------------|
| 拦截点 | nftables prerouting redirect :46569 | ip rule 9002 → TUN |
| 源 IP | 172.18.0.2（原始，未变） | 198.18.0.1（TUN 栈 NAT） |
| 经过核心引擎 | ✅ 是（规则匹配、代理选择） | ❌ 否（TUN 栈直接转发） |
| 规则引擎日志 | `[TCP] 172.18.0.2:xxx → ... match ...` | 无 `[TCP]` 日志 |

---

### 4.5 外部入站流量

**场景：** 外部机器 `203.0.113.5` 访问本机 `192.168.1.5`

#### 4.5.1 外部 TCP 入站（理论分析）

**问题：** 所有外部入站 TCP（如 SSH、HTTP 服务等）会被强制吸入 Mihomo 透明代理端口，可能导致：
- 外部 SSH 到本机无法正常建立
- 需在 nftables 中添加豁免规则

**验证盲区：** 本机 SSH `192.168.1.5` 实际走 OUTPUT hook（`oif=lo`），不经过 PREROUTING，无法验证。需另一台物理机或虚拟机从外部发起连接。

#### 4.5.2 外部 ICMP/UDP 入站（经实验验证）

**实测验证：**

```bash
# 从本机 ping 自己的外部 IP
ping 192.168.1.5

# 在 Meta 设备上 tcpdump 监听
sudo tcpdump -ni Meta icmp  # → 没有抓到包
```text

得出结论：外部入站 ICMP/UDP **不被吸入 TUN**，因为 `ip rule 0`（`lookup local`）优先级最高，目的地为本机的包直接被 local 表捕获，正常交付。

> **注意：** 此实验使用本机 ping 自己的外部 IP。严格来说数据包在本机内部经由路由/lo 处理，与真正物理网卡上外部流量仍有差异。但基于 rule 0 的优先级分析，结论应是可靠的。

---

## 5. 关键机制总结表

| 协议 | 流量来源 | 拦截点 | 规则/链 | 是否进核心引擎 | 源 IP 变化 |
|------|---------|--------|---------|--------------|-----------|
| TCP | 本机 | OUTPUT hook | `oif=Meta tcp redirect :46569` | ✅ | 保持（192.168.1.5） |
| TCP | 容器 | PREROUTING hook | `meta l4proto tcp redirect :46569` | ✅ | 保持（172.18.0.2） |
| TCP | 外部入站 | PREROUTING hook | `meta l4proto tcp redirect :46569` | ✅（有风险） | 保持（外部 IP） |
| ICMP/UDP | 本机 | ip rule 9002 | `not iif lo → table 2022 → Meta` | ❌ | 改为 198.18.0.1 |
| ICMP/UDP | 容器 | ip rule 9002 | `not iif lo → table 2022 → Meta` | ❌ | 改为 198.18.0.1 |
| ICMP/UDP | 外部入站 | ip rule 0（local） | `from all lookup local` | ❌ | 不变（正常交付） |

### 拦截优先级链

---

## 6. TUN 栈与核心引擎的区分

Mihomo 内部有两个不同的处理层：

| 层 | 处理对象 | 行为 |
|----|---------|------|
| **TUN 栈** | 从 TUN 设备读取的原始 IP 包 | 对 TCP 送核心引擎；对 ICMP/UDP 做 NAT 后直接转发 |
| **核心引擎** | 从 socket 收到的流（代理端口 / 透明代理端口） | 规则匹配 → 代理选择 → 协议封装 → 经代理节点发出 |

日志中可清晰区分：
- `[TCP]` 开头 → 核心引擎处理
- `[TUN]`、`write/read ICMPv4` 开头 → TUN 栈处理

---

## 7. 盲点与待验证项

### 7.1 外部 TCP 入站测试

**待验证：** 从另一台物理机/虚拟机 SSH 到本机 `192.168.1.5:22`，观察是否被 `prerouting redirect :46569` 拦截破坏。

**修复方案（如需）：**

```bash
nft add rule inet mihomo prerouting ip daddr 192.168.1.5 tcp dport {22, 9090} return
```text

### 7.2 可能的 `bypass` 规则

当前 Mihomo 规则中有 `GEOIP,lan,DIRECT,no-resolve`，但这条规则在**核心引擎**内生效，不阻止 TCP 被 redirect 截获。入站 TCP 在 nftables 阶段就被拦截，核心引擎的规则无法阻止这一过程。

### 7.3 宿主机/容器出站延迟差异

容器 TCP 和本机 TCP 都经核心引擎代理，但路径不同：
- 本机：OUTPUT redirect → socket
- 容器：PREROUTING redirect → socket

两者理论上延迟一致，可通过实际测试验证是否存在差异。

---

## 验证与自查

1. `ip route get 1.1.1.1` 与 `ip route get 1.1.1.1 from 172.18.0.2 iif br-700ced5fc520` 分别模拟本机/容器流量，均落入表 2022（dev Meta）
2. `sudo nft list chain inet mihomo prerouting | grep "redirect to :46569"` 观察计数器：容器一次 wget 后增量约为 3（SYN+请求+ACK）
3. 容器 `ping 1.1.1.1` 延迟约 192ms（经代理转发），`ping 192.168.1.1` 约 1.2ms（直连），对比确认转发路径
4. Mihomo debug 日志可区分两层处理：`[TCP]` 开头为核心引擎，`write/read ICMPv4` 开头为 TUN 栈 NAT 转发

## 附录

### A. 常用诊断命令

```bash
# 查看 nftables 规则集
sudo nft list ruleset

# 查看策略路由规则
ip rule show

# 查看所有路由表
ip route show table all

# 查看特定路由表
ip route show table 2022
ip route show table main

# 模拟路由决策（查看包会走哪个路由表）
ip route get 1.1.1.1 from 172.18.0.2 iif br-700ced5fc520

# 查看 nftables 计数器
sudo nft list chain inet mihomo prerouting | grep "redirect to :46569"

# 查看 Mihomo debug 日志
sudo journalctl -u mihomo --since "1 min ago"

# 抓包
sudo tcpdump -ni Meta icmp
sudo tcpdump -ni lo port 46569
sudo tcpdump -ni wlp0s20f3 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'

# conntrack 连接跟踪（需 root）
sudo conntrack -E -p tcp --dport 46569
```text

### B. 相关文件路径

| 文件 | 路径 |
|------|------|
| Mihomo 配置文件 | `/opt/mihomo/etc/config.yaml` |
| Mihomo 二进制 | `/opt/mihomo/bin/mihomo` |
| Systemd unit | `/etc/systemd/system/mihomo.service` |
| 旧配置备份 | `/etc/mihomo/config.yaml` |

### C. 对话中关键日志输出