适用环境：Nikki 1.26.1、Mihomo 内核与 OpenWrt 25.12.x。不同版本的界面字段可能存在差异，请以实际页面和最终启动配置为准。
本文面向主路由或旁路网关场景，系统梳理 Nikki 的插件配置、订阅、混入配置、TUN、Fake-IP、DNS 劫持、IPv4/IPv6 双栈透明代理、访问控制与排障方法。修改前请备份 /etc/config/nikki、本地 YAML 与混入文件。
适用版本：Nikki 1.26.1，Mihomo 内核，OpenWrt 25.12.x。不同版本的字段可能略有增删。 推荐场景：OpenWrt 作为主路由或旁路网关，规则模式、Fake-IP、IPv4/IPv6 双栈、全 LAN 透明接管。
先说结论：核心运行不等于透明代理已接管
本文不提供所谓的“一键最优配置”，而是把 OpenWrt 上 Nikki 的每一个主要选项讲明白：它控制的是 Mihomo 内核，还是 OpenWrt 防火墙；为什么有人开了 IPv6 仍然泄漏；Fake-IP 为什么一定要配 DNS 劫持；TUN 的 System、gVisor、Mixed 又该怎么选。
先说结论：Nikki 页面显示“核心运行中”，只代表 Mihomo 进程启动了，不代表局域网流量一定已经被接管。真正决定是否接管的是配置文件、混入配置和代理配置三层共同作用。只要其中一层没配对，就可能出现“节点能测速、面板能打开，但手机仍然直连”的情况。
第一章：先建立正确的三层模型
理解 Nikki，先记住三个层次。
第一层是“配置文件或订阅”。它通常提供节点、代理组、规则集和基础的 Mihomo 配置。
第二层是“混入配置”。Nikki 会把这里的设置合并到订阅里，生成最终交给 Mihomo 的启动配置。比如启用 Fake-IP、设置 DNS 监听端口、打开嗅探、指定 TUN 栈，都属于这一层。
第三层是“代理配置”。这一层不是 Mihomo YAML，而是 Nikki 在 OpenWrt 上创建 nftables、策略路由和 TUN 路由，用来决定哪些路由器流量、哪些 LAN 设备、哪些 IPv4 和 IPv6 数据包要送进 Mihomo。
可以把它理解成：
设备流量
↓
代理配置：要不要抓、抓哪台设备、抓 IPv4 还是 IPv6
↓
混入配置：Mihomo 用什么入口、DNS、TUN 和嗅探方式处理
↓
订阅规则：这个域名最终走直连、代理组还是拒绝所以“代理配置里的 IPv6 代理”与“混入配置里的 IPv6”并不是同一个开关。前者负责把 IPv6 流量抓进来，后者负责让 Mihomo 解析和处理 IPv6。想完整支持双栈，通常两边都要正确。
还有一个贯穿整个页面的词叫“不修改”。它不是“关闭”，而是“不覆盖订阅原来的值”。订阅里开着，它就继续开；订阅里没写，就使用 Mihomo 默认值。因此做教程时，不要把“不修改”和“禁用”混为一谈。
第二章：状态与插件配置
2.1 插件版本、核心版本、核心状态
“插件版本”是 LuCI 界面和 Nikki 管理脚本的版本；“核心版本”是 Mihomo 的版本。两者不是一个东西。界面能正常打开，不代表内核功能一定匹配；反过来，更新内核也不会自动更新 Nikki 的管理逻辑。
“核心状态”只检查 Mihomo 是否在运行。它不能单独证明 DNS 劫持、nftables 和 IPv6 接管已经生效。验证透明代理，还要看面板连接来源、Nikki 的 nftables 规则，以及客户端出口 IP。
2.2 重载服务、重启服务、更新面板、打开面板
“重载服务”用于重新生成运行配置并让服务重新载入，适合普通配置调整。“重启服务”会完整停止再启动，改了 TUN、监听端口、透明代理模式或防火墙接管时，优先使用重启，避免旧路由和旧连接残留。
“更新面板”只更新 Zashboard、MetaCubeXD 这类前端静态文件，不更新 Mihomo 内核，也不更新订阅。“打开面板”则连接外部控制 API；打不开时应检查 API 监听地址、密钥和防火墙，不要先去更换节点。
2.3 启用
这是 Nikki 服务的总开关。关闭以后，Mihomo 不会由 Nikki 启动，Nikki 创建的透明代理规则也会被清理。排障时可以关闭，但不要把它当作“临时直连”按钮频繁切换，因为现有连接可能需要重新建立。
推荐：正常使用时开启。
2.4 选择配置文件
这里选择本地上传的 YAML，或者某一条订阅。Nikki 每次启动都会把所选内容复制到运行目录，再根据是否开启“仅核心”决定要不要执行混入和透明代理管理。
推荐：普通用户选择维护中的订阅；自己完整维护 YAML 的用户选择本地文件。不要同时在订阅缓存文件和混入页面里改同一个字段，否则以后很难判断是谁覆盖了谁。
2.5 启动延迟
启动延迟是路由器开机后等待多少秒再启动 Nikki。它适合 PPPoE、USB 网卡、旁路由上游或者存储挂载需要较长时间就绪的环境。
推荐：普通有线 WAN 使用 0；如果开机时经常订阅下载失败、Geo 数据加载失败或者上游接口还没起来，可以设置 5 到 15 秒。它只影响启动时机，不会改善日常网速。
2.6 定时重启与 Cron
定时重启会按照 Cron 表达式周期性重启 Nikki。比如 0 4 * * * 表示每天凌晨四点。它适合极少数长期运行后内存异常、节点连接不释放的环境，不是必须设置的“优化”。
推荐：稳定运行就关闭。不要用每小时重启来掩盖配置错误，因为重启会打断连接。只有确认存在长期运行问题时，才安排在低峰期每天或每周重启。
2.7 检查配置文件
开启后，Nikki 在真正启动前会调用 mihomo -t 检查最终配置的语法和引用。配置不合法时会拒绝启动，并在核心日志里说明错误位置。
推荐：开启。代价只是启动多花一点时间，却能避免一个缩进或字段错误导致核心反复崩溃。
2.8 仅核心
这是最容易误解的选项。“仅核心”不是轻量模式，也不是关闭网页面板。勾选以后，Nikki 仍然可以读取订阅、下载订阅、执行配置测试、应用 procd 的资源限制和环境变量，并启动 Mihomo；但是它会跳过 Nikki 的混入配置，也不会创建 Nikki 的 nftables、策略路由、TUN 路由和 LAN DNS 劫持。
换句话说，勾选“仅核心”以后，页面可能仍显示“核心运行中”，但“代理配置”页面里的全 LAN 接管、MAC 排除、IPv6 代理和 DNS 劫持都不再由 Nikki 执行。只有你的原始 YAML 已经完整配置了 tun、auto-route、auto-redirect，或者你只想手动使用 HTTP/SOCKS 端口时，才适合开启。
推荐：主路由透明代理不要勾选；原生 Mihomo 高级用户才勾选。
2.9 procd：快速重载
快速重载尝试用信号让 Mihomo 重新读取配置，减少完整重启造成的断线。它适合只改变节点、代理组或普通规则。改 TUN 设备、监听端口、路由和 nftables 这类结构性设置时，完整重启更可靠。
推荐：追求稳定就保持关闭；需要频繁切换配置并理解热重载边界时再开启。修改 GOMAXPROCS、GOMEMLIMIT、安全路径、任何 RLIMIT 或更换核心二进制后，必须完整重启；只发 HUP 不会把这些新值应用到现有进程。
2.10 procd：资源限制
资源限制页里的软限制和硬限制，来自 Linux 的 RLIMIT。
- “进程数软/硬限制”限制核心及其子进程可以使用的进程或线程资源。
- “地址空间软/硬限制”限制进程可映射的总虚拟内存。
- “堆大小软/硬限制”限制数据段或堆内存。
- “栈大小软/硬限制”限制线程栈。
- “打开文件数软/硬限制”限制 socket 和文件描述符数量；连接很多时这个值尤其重要。
软限制是进程当前使用的门槛，硬限制是软限制能够提高到的上限，软限制不能高于硬限制。普通用户让内存、进程和栈限制保持系统默认；连接较多的路由器可以把打开文件数软、硬限制都设为 65536。盲目压低内存或文件数，结果通常不是“更省资源”，而是高并发时随机断流、无法建立连接或者核心启动失败。内存相关输入按字节处理，填写 512 不是 512 MB，而是 512 字节。
2.11 procd：环境变量
GOMAXPROCS 限制 Go 运行时同时使用多少个 CPU 执行线程。留空时 Go 会根据系统 CPU 自动决定。除非一台 PVE 主机上的 OpenWrt 必须严格限核，否则保持默认。
GOMEMLIMIT 是 Go 的软内存目标，不等同于硬性上限。设得过低会让垃圾回收非常频繁，CPU 占用反而上升。普通用户保持默认。
“安全路径”用于额外允许 Mihomo 访问指定目录，例如把证书、规则集或 provider 放在 Nikki 默认目录之外。不要为了省事添加根目录 /，那会扩大核心可访问的文件范围。
“禁用回环检测”是关闭 Mihomo 的代理回环保护。默认不要勾；只有确认回环检测误判时才临时测试，否则错误路由可能让流量在代理中循环。
“禁用 quic-go 的 GSO”用于处理某些网卡、虚拟化或内核上的 QUIC 分段卸载兼容问题。正常情况下不勾；出现 QUIC 高丢包、UDP 断流或报错时再尝试。
“禁用 quic-go 的 ECN”用于排查网络对显式拥塞通知支持不良的问题。正常不勾；只有 QUIC 握手异常且日志指向 ECN 时再关闭。
“跳过系统 IPv6 检查”会让 Mihomo 不再依据系统检测结果判断 IPv6 是否可用。正常不勾；只有系统检测为不可用、但你已经确认 IPv6 路由完全正常时才开启。它不能修复缺失的 IPv6 默认路由。
第三章：配置文件、订阅与编辑器
3.1 上传配置文件
这里上传本地 Mihomo YAML。上传只是保存文件，不代表已经选中它，也不会自动重启服务。上传后还要回到插件配置，选择该文件并保存应用。
本地文件适合完整自建配置。订阅用户不要把长期修改直接写进供应商文件，因为下一次更新就可能覆盖；个性化内容应尽量放到混入配置。
3.2 订阅名称
订阅名称只用于 Nikki 页面显示和日志。缓存文件实际按 UCI section ID 命名，改订阅名称不会重命名缓存文件。建议使用简短、唯一、便于识别的名称；它不是代理组名称，也不会改变服务商后台的套餐名称。
3.3 已用、总量、到期时间、更新时间
这些是订阅服务器通过响应头返回的流量和到期信息，属于只读状态。显示为空不一定代表订阅失效，也可能是服务商没有提供标准响应头。
3.4 更新按钮、订阅信息 URL、订阅 URL
“更新”立即下载订阅缓存，但不会让已经运行的核心自动切换到新缓存；更新成功后还要重载 Nikki。“订阅 URL”是实际 YAML 地址，属于敏感信息，录视频时一定打码。“订阅信息 URL”可用于单独获取套餐流量信息，服务商没有提供就留空。
更新失败时，应用日志通常只会显示“订阅下载失败”，因为下载命令没有把 curl 的 HTTP 状态码、证书或 DNS 细节写入日志。要进一步定位，需要在保护好订阅 URL 的前提下手动执行 curl 测试。不要在公开日志或视频里暴露完整订阅链接，因为链接里通常包含账户令牌。
3.5 User-Agent
User-Agent 告诉订阅服务器当前客户端类型，可选 clash、clash.meta 和 mihomo。一些服务商会根据它返回不同格式。
推荐先按服务商要求选择；没有说明时可从兼容面较广、也是页面默认的 clash 开始。服务商需要 Meta/Mihomo 专属协议或字段时，再使用 clash.meta 或 mihomo。它不会伪装浏览器，也不会提高代理速度。
3.6 优先使用：远程与本地
选择“远程”时，每次 Nikki 启动或重载都会先尝试更新订阅；下载失败时，如果旧缓存还在，会继续使用旧缓存。选择“本地”时，只要缓存存在，启动就不联网更新；只有缓存缺失时才下载。
推荐：希望节点随服务商更新就选远程；需要固定版本、担心上游临时下发错误配置，或者路由器启动时网络尚未就绪，就选本地并手动更新。
3.7 编辑器里的文件类型
编辑器可以打开本地配置、订阅缓存、规则 provider、代理 provider、混入文件和“启动配置”。这里要特别区分：
- 订阅缓存会在更新时被覆盖。
- “启动配置”是 Nikki 合并后的最终产物，下一次重启也会重新生成，适合排障查看，不适合长期修改。
- “混入文件”是持久化的高级自定义位置，适合界面没有暴露的 Mihomo 字段。
直接编辑 YAML 前先备份。缩进错误、重复字段和不存在的代理组名称，都会导致启动检查失败。
第四章：混入配置——真正交给 Mihomo 的参数
4.0 先解释“覆盖、追加、不修改”
混入配置不是另一份独立配置，而是对所选订阅进行二次合并。
“不修改”代表保留订阅值或 Mihomo 默认值；“启用”和“禁用”才是明确写入 true 或 false。带“覆盖”二字的开关更要谨慎：开启以后，Nikki 会先删除订阅中对应的原值，再用页面里的列表重建。列表为空时，就可能等于把服务商原来的配置清空。
反过来也一样：表格里即使已经有内容，只要没有勾对应的“覆盖”，这些内容也只是保存在页面配置中，不会进入最终 YAML。判断它是否生效，应该看编辑器里的“启动配置”，不能只看表格有没有值。
“追加规则”和“追加规则集”则是在现有配置上加入内容。规则有先后顺序，越靠前优先级越高，所以任何自定义直连、代理或拒绝规则都要确认排列位置。
4.1 全局配置：日志级别
日志级别从安静到详细依次是 silent、error、warning、info、debug。
silent基本不记录，不适合排障。error只看错误。warning兼顾日常使用和日志体积。info适合临时观察 DNS、规则和节点切换。debug信息量很大，只应短时间使用。
推荐日常选择 warning；遇到问题临时改 info，仍无法定位再用 debug。调试结束记得改回，否则 tmpfs 日志会快速增长。
4.2 模式：全局、规则、直连
全局模式把大部分流量交给全局代理组；规则模式按照订阅规则决定直连或代理；直连模式尽量不使用节点。
推荐选择“规则模式”。全局模式适合临时验证节点，直连模式适合临时排除代理故障，它们都不是日常精细分流的首选。
4.3 匹配进程
匹配进程让 Mihomo 尝试识别连接来自哪个本机进程，可选 off、strict 和 always。
off不查进程，开销最低。strict在规则需要进程信息时严格查找。always尽可能为每条连接查找进程。
OpenWrt 主要接管的是其他 LAN 设备，路由器无法看到手机内部是哪个 App 发起，因此进程匹配对 LAN 转发流量基本没有意义。推荐 off。只有需要给路由器本机进程写 PROCESS-NAME 规则时才考虑开启。
4.4 出站接口
出站接口用于把 Mihomo 的外连 socket 绑定到指定 OpenWrt 网络接口，常用于多 WAN、VPN 共存或避免路由回环。
单 WAN 环境推荐“不修改”，让系统路由表选择。多 WAN 用户可以指定真正的出口，但选错接口会导致所有节点连接失败。这里选择的是 OpenWrt 逻辑网络，不是代理节点。
4.5 IPv6
这里的 IPv6 控制 Mihomo 是否接受和处理 IPv6 连接能力，并影响 TUN/Fake-IP6 等行为。它不负责决定 DNS 是否返回 AAAA；那是 DNS 页面的独立 IPv6 开关。它也不负责在防火墙层抓取客户端 IPv6；抓取动作还要在“代理配置”里开启 IPv6 代理和 IPv6 DNS 劫持。
有完整 IPv6 默认路由并且希望双栈使用时选择启用；完全没有 IPv6 的网络可以禁用。不要为了掩盖泄漏直接关 IPv6，正确做法是同时接管 IPv6 DNS 和 IPv6 流量。
4.6 统一延迟
统一延迟让不同类型节点的延迟测试采用更一致的计算方式，更接近从建立连接到收到有效响应的完整耗时。它主要影响面板显示和自动选择组的比较，不会直接给线路“降延迟”。
推荐启用，让不同协议的测速结果更有可比性。
4.7 TCP 并发
TCP 并发不是同时使用多个代理节点，而是一个域名解析出多个地址时并行尝试连接，使用最先成功的那个，效果类似更积极的 Happy Eyeballs。
推荐启用，可以减少某个 IPv4 或 IPv6 地址不可达造成的等待；代价是连接建立瞬间会多发少量尝试。在连接数极其敏感的环境可以关闭。
4.8 TCP Keep Alive
TCP Keep Alive 是内核级保活探测。连接长时间没有业务数据时，系统发送很小的探测包，用来发现已经失效的对端，并降低 NAT 或防火墙过早回收空闲连接的概率。它不是 HTTP Keep-Alive，也不作用于 UDP。
“禁用 TCP Keep Alive”是反向开关：选择启用，意思是启用“禁用功能”，也就是把保活关闭。普通用户保持“不修改”，不要禁用。
“Keep Alive 空闲”表示空闲多久后开始探测，“Keep Alive 间隔”表示探测之间隔多久。单位按 Mihomo 字段使用秒。没有明确的运营商 NAT 超时问题时，两个都保持“不修改”；设得太短会制造无意义探测，设得太长又起不到及时发现死连接的作用。
4.9 外部控制：UI 路径、名称和下载地址
UI 路径是面板静态文件所在目录；UI 名称用于区分面板目录或访问路径；UI URL 是“更新面板”时下载 Zashboard、MetaCubeXD、YACD 等压缩包的地址。
普通用户选择 Nikki 提供的预设 URL 即可。不要使用来历不明的面板包，因为面板能够调用 Mihomo API，看到连接记录并修改代理组。
4.10 API 监听与 API 密钥
API 监听对应 Mihomo 的外部控制端口，例如 127.0.0.1:9090 只允许路由器本机访问，0.0.0.0:9090 或 [::]:9090 则可能允许 LAN 双栈访问，实际范围还受 OpenWrt 防火墙限制。
需要从电脑打开面板时，可以监听 LAN，但必须设置高强度 API Secret。绝对不要把控制端口直接映射到公网。拿到 API 权限的人可以查看连接、切换节点、关闭连接，风险远高于一个普通状态页面。
API TLS 监听提供 HTTPS 控制接口；TLS 证书和私钥填写文件路径，ECH Key 属于更高级的 TLS/ECH 配置。只在确实需要加密远程控制、并且理解证书权限和路径时配置。家庭 LAN 中更简单的方案是只在内网监听并设置密钥。
4.11 保存代理选择
开启以后，Mihomo 会缓存面板中手动选择的节点和策略组，下次重启继续使用。关闭以后，重启后回到配置文件默认选择。
推荐启用。测试订阅默认策略、或者希望每次启动都回到自动选择时再关闭。
4.12 入站配置：允许 LAN
“允许 LAN”控制其他局域网设备能否直接访问 Mihomo 的 HTTP、SOCKS 和 Mixed 手动代理端口。透明代理通过 nftables 接管，并不等于一定需要开放这些手动端口。
如果只用透明代理，可以保持不修改或禁用；需要在浏览器、电视或其他设备手工填写代理地址时才启用，并配合认证和防火墙。开放以后不要把监听端口暴露到 WAN。
4.13 HTTP、SOCKS、Mixed、Redirect、TPROXY 端口
HTTP Port 是传统 HTTP 代理入口；SOCKS Port 是 SOCKS4/5 入口；Mixed Port 用一个端口同时接受 HTTP 和 SOCKS。它们主要给手动代理客户端使用。
Redirect Port 是透明代理中 NAT Redirect 模式接收 TCP 的端口；TPROXY Port 是透明代理中 TPROXY 模式接收 TCP 或 UDP 的端口。后两个必须与“代理配置”选择的模式匹配，否则 Nikki 把数据送到一个没有监听的端口，结果就是全网断流。
推荐不要随意修改 Nikki 生成的默认端口。若修改，先确认没有被其他程序占用，并重启服务重建规则。
4.14 覆盖认证、用户名和密码
开启“覆盖认证”后，Nikki 会删除订阅中原来的认证列表，改用页面中启用的用户名和密码。它主要保护 HTTP、SOCKS 和 Mixed 入站端口，不是机场节点的密码，也不是外部控制 API Secret。
如果允许 LAN 使用手动代理端口，建议设置独立强密码；只做透明代理且端口不开放时可以不配置。注意“覆盖已开启但列表为空”可能把原认证清掉。
4.15 TUN：启用与设备名称
TUN 是一个虚拟网卡。Nikki 可以把被标记的 TCP、UDP 或 IPv6 流量路由到这张网卡，再由 Mihomo 在用户态处理。
只要代理配置里的 TCP 或 UDP 模式选择了 TUN，这里就必须启用，并且设备名称必须一致。推荐设备名保持 nikki，不要与 WireGuard、OpenVPN 或其他 TUN 设备重名。
4.16 TUN 栈：System、gVisor、Mixed
System 使用 Linux 系统网络栈，性能高、资源占用低；gVisor 使用用户态网络栈，隔离和兼容路径不同，但 CPU、内存开销通常更大；Mixed 通常让 TCP 使用 System、UDP 使用 gVisor，兼顾性能和 UDP 兼容性。
推荐从 Mixed 开始。追求极限吞吐并确认 UDP 正常，可以尝试 System；遇到特殊 UDP、游戏或 NAT 兼容问题，可以对比 gVisor。切换后要完整重启并分别测试 TCP、UDP 和 IPv6，不能只看网页能否打开。
4.17 TUN MTU
MTU 是 TUN 接口一次承载的最大 IP 包大小。过大可能在 PPPoE、隧道套隧道或某些节点协议上触发分片和 PMTU 黑洞，表现为小网页能开、大文件卡住；过小则增加包数量和 CPU 开销。
推荐优先“不修改”或使用 Nikki 默认值。PPPoE 外层 MTU 常见为 1492，但 TUN 是内部虚拟接口，不能简单看到 PPPoE 就机械地填 1492。只有出现明确的 MTU 症状时，再从 1500、1400 一类保守值逐步测试。
4.18 TUN GSO 与最大分段大小
GSO 是通用分段卸载，让系统把较大的数据块交给网络栈后再分段，可以减少每包处理开销、提高高速转发吞吐。最大分段大小限制一次聚合的上限。
它不是前面 procd 页面里的“禁用 quic-go GSO”：一个作用于 TUN 转发，另一个只针对 quic-go 的 UDP/QUIC。
推荐先保持默认。千兆代理 CPU 成为瓶颈时可以尝试启用；如果随后出现 UDP 异常、部分网站打不开或虚拟网卡驱动报错，就关闭。最大分段大小没有基准测试不要乱填。
4.19 覆盖 TUN DNS 劫持
开启后，会用列表中的 tcp://any:53、udp://any:53 等值覆盖订阅里的 tun.dns-hijack。这是 Mihomo TUN 内部的 DNS 劫持方式。
如果已经使用 Nikki“代理配置”页面的 IPv4/IPv6 DNS 劫持，通常无需再覆盖 TUN DNS 劫持。两套机制不是越多越安全，重复配置反而增加排障难度。只有准备让 YAML/TUN 自己管理 DNS 接管时才开启。
4.20 DNS 启用、缓存算法和监听地址
DNS“启用”决定是否启动 Mihomo 内置 DNS。Fake-IP 和 Nikki 的 DNS 劫持都依赖它；使用 Fake-IP 时必须启用。
缓存算法可选 LRU 和 ARC。LRU 逻辑简单、资源开销低；ARC 会在“最近使用”和“经常使用”之间自适应，面对大量不同域名时命中率通常更好。x86 或内存充足设备推荐 ARC，极低内存设备可选择 LRU。
DNS 监听地址决定 Mihomo 在哪里接收查询，例如 [::]:1053 表示在 1053 端口提供双栈监听。不要让 Mihomo 和 dnsmasq 同时抢占 53 端口。使用 Nikki 防火墙劫持时，推荐让 Mihomo 监听非 53 端口，再由 nftables 把客户端的 53 重定向过去。
4.21 DNS 页面里的 IPv6
这个 IPv6 主要决定 DNS 是否返回 AAAA 结果，不等于“DNS 是否能通过 IPv6 地址被访问”，也不等于“IPv6 流量是否已被透明代理”。
双栈网络推荐启用，同时确保代理配置中的 IPv6 代理和 IPv6 DNS 劫持也开启。没有 IPv6 出口时可以禁用 AAAA，减少客户端先尝试不可达 IPv6 的等待。
4.22 DNS 模式：Redir-Host 与 Fake-IP
Redir-Host 返回域名真实 IP，Mihomo 再结合 DNS 映射和嗅探判断域名。优点是兼容性直观，缺点是更依赖 DNS 解析速度和污染防护。
Fake-IP 会从保留测试网段中给域名分配一个假地址。客户端连接假地址时，Mihomo 根据映射恢复原域名，再执行域名规则和真实解析。优点是域名规则稳定、响应快、抗污染能力强；缺点是局域网发现、某些游戏、STUN、银行或强校验应用可能需要加入过滤列表。
推荐透明代理优先 Fake-IP。如果经常遇到无法维护的特殊应用兼容问题，再考虑 Redir-Host，而不是一出问题就关闭整个 DNS 劫持。
4.23 Fake-IP IPv4/IPv6 地址池与 TTL
Fake-IP Range 是 IPv4 假地址池，常见为 198.18.0.1/16。这是基准测试保留网段，不是公网地址。不要把它添加到“保留地址绕过”中，否则客户端拿到假 IP 后，流量反而绕过 Mihomo，网站就会打不开。
Fake-IP6 Range 是 IPv6 假地址池。只有确认所用 Mihomo 版本、TUN 路由和插件辅助路由都支持时才设置；普通双栈环境也可以只让 AAAA 返回真实 IPv6，再由透明代理接管。没有 Fake-IP6 地址池不等于 IPv6 泄漏。
Fake-IP TTL 是返回给客户端的假地址缓存时间，不是节点连接寿命。一般保持订阅或核心默认，过短会增加 DNS 查询，过长则让客户端更久持有旧映射。
4.24 覆盖 Fake-IP 过滤器、过滤模式与缓存
Fake-IP 过滤器用于指定哪些域名不要返回假 IP。Blacklist，也就是阻止模式，表示列表中的域名排除 Fake-IP、返回真实地址；Whitelist 表示只有列表命中的域名使用 Fake-IP；Rule 模式则按支持的规则表达式判断。
家庭网络通常使用 Blacklist，并保留 .lan、.local、局域网设备域名，以及确实不兼容 Fake-IP 的应用域名。不要复制几千条来历不明的过滤列表，过滤范围越大，Fake-IP 带来的域名分流优势越少。
“覆盖 Fake-IP 过滤器”开启时会替换订阅原列表。想保留服务商已有兼容项时不要随便覆盖。
尤其不要只填 +.lan、+.local 就覆盖整张表：这样可能同时丢掉订阅或核心为 Windows 联网检测、局域网发现等准备的兼容项。正确做法是先查看原列表，再形成一份完整替代表。
Fake-IP Cache 用于保存域名和假地址映射，让核心重启后尽量保持一致。推荐启用，可以减少重启后旧连接对应不上新映射的问题。
4.25 DNS 遵循规则
开启后，Mihomo 发出的 DNS 请求也会参考代理规则，决定直连还是通过节点。例如国外 DoH 可以按规则走代理，降低污染风险。
但它有一个经典循环：要连接代理节点，先要解析节点域名；解析请求又想走代理，而代理还没连上。因此启用“遵循规则”时，一定要正确配置 proxy-server-nameserver，专门解析代理服务器域名。
推荐：订阅已经提供完整 DNS 架构时保持其设置；自行配置时，先准备节点域名的启动解析器，再开启遵循规则。
4.26 DoH 优先 HTTP/3
开启后，DoH 在可用时优先使用 HTTP/3，也就是 QUIC/UDP。网络质量好时可能降低握手延迟，但有些运营商、校园网、企业防火墙或节点对 UDP 不友好，反而会超时。
推荐默认关闭。确认 UDP 稳定并愿意承担回退等待时再开启。Mihomo 官方强烈不建议把 respect-rules 与 DoH prefer-h3 同时开启；常用的稳定组合是“DNS 遵循规则开启、DoH HTTP/3 关闭”。它不是“新版协议一定更快”的开关。
4.27 使用系统 Hosts、使用配置 Hosts、覆盖 Hosts
“使用系统 Hosts”读取 OpenWrt 系统的 /etc/hosts 等主机映射；“使用 Hosts”读取 Mihomo 配置文件里的 hosts；“覆盖 Hosts”则用页面编辑的域名和 IP 列表替换订阅中的 hosts。
普通家庭网络可启用系统 Hosts，方便解析路由器和静态主机名；配置 Hosts 按订阅需求启用。只有明确要统一维护自定义映射时才打开覆盖，避免把订阅已有映射清掉。
4.28 覆盖 Nameserver 与五种类型
开启“覆盖 Nameserver”后，可以为不同角色配置 DNS：
default-nameserver是启动解析器，主要用于解析 DoH、DoT 服务器自己的域名，通常应填写可直接访问的纯 IP DNS，避免“解析 DNS 还需要 DNS”的死循环。proxy-server-nameserver专门解析代理节点服务器域名，是防止 DNS 遵循规则形成代理循环的关键。direct-nameserver用于最终判定为 DIRECT 的域名，让国内直连域名可以使用合适的本地解析器。nameserver是主要解析器，处理一般查询。fallback是备用解析器，常用于可信境外 DNS；是否真正发挥预期作用还取决于订阅中的 fallback 相关逻辑。
地址可以是传统 UDP/TCP DNS，也可以是 DoH、DoT 等 Mihomo 支持的格式。不要只追求“全部加密”，启动解析、路由和证书域名之间必须没有循环。
普通用户优先沿用维护良好的订阅 DNS。自己搭建时可使用“国内直连解析器负责启动和直连域名、可信 DoH 负责需要代理的域名”的思路。
4.29 Proxy Server Nameserver Policy
这个策略可以按匹配器为不同的代理服务器域名指定启动解析器。例如某组节点域名使用国内 DNS，另一组特殊域名使用指定解析器。它解决的是“怎么解析代理节点本身”，不是普通网站分流。
“覆盖”开启后，设计意图是用页面策略控制节点域名解析。绝大多数用户不需要设置；多家节点供应商域名在不同网络中解析表现差异明显时再使用。Nikki 1.26.1 在这一项的清理逻辑与其他“覆盖”项不完全一致，订阅中未同名的旧策略可能继续保留，因此高级配置必须检查最终启动 YAML。
4.30 Direct Nameserver Follow Policy
开启后，直连域名使用 direct-nameserver 时，也会继续参考 nameserver-policy 的精细匹配。关闭时，直连查询更直接地使用 direct-nameserver。
需要对个别直连域名指定特殊 DNS 时开启；没有复杂 DNS 策略时保持不修改，避免一条策略同时影响代理解析和直连解析。
4.31 Nameserver Policy
Nameserver Policy 是按域名、规则集或支持的匹配表达式选择 DNS。例如让国内域名走阿里 DNS，让非中国域名走可信 DoH。它决定“向谁查询”，并不直接决定最终流量走哪个节点。
规则必须从具体到宽泛，避免后面的通用匹配抢走特殊域名。覆盖前要确认订阅原策略是否有节点解析、广告过滤或防污染逻辑。
4.32 嗅探器总开关
嗅探器会从 HTTP Host、TLS SNI 和 QUIC 握手中尝试恢复域名。它不能解密 HTTPS 内容，只读取协议握手中本来可见的主机信息。主要作用是：应用直接连接 IP，或者 DNS 映射不足时，仍能让域名规则命中。
推荐启用，尤其是透明代理和规则模式。但它不是万能的；ECH、私有协议和完全加密的握手可能无法嗅探。
4.33 嗅探 Redir-Host 与纯 IP
“嗅探 Redir-Host”允许在真实 IP DNS 模式下结合 DNS 映射进一步恢复域名；“嗅探纯 IP”则针对没有可用 DNS 映射、应用直接访问 IP 的连接尝试识别协议域名。
Redir-Host 用户建议开启对应嗅探；Fake-IP 用户主要依靠假 IP 映射，但纯 IP 嗅探仍可帮助硬编码地址的应用。若个别 App 因嗅探误判打不开，再针对域名加入忽略列表，不必直接关闭总开关。
4.34 强制嗅探域名与忽略嗅探域名
强制列表让指定域名即使已有映射也执行嗅探；忽略列表让指定域名不被嗅探结果覆盖。两者适合修复个别 CDN、多域名证书、游戏和银行应用的兼容问题。
“覆盖”同样意味着替换订阅列表。推荐默认沿用订阅，只对已经复现的问题添加最小范围规则。
4.35 按协议嗅探：HTTP、TLS、QUIC
这里分别指定 HTTP、TLS、QUIC 要检查的端口范围。“覆盖目标地址”表示嗅探成功后，把连接逻辑目标从原 IP 改为域名，以便域名规则和域名解析真正参与后续连接。
注意：页面表格里已经列出 HTTP、TLS、QUIC，不代表这些协议嗅探已经生效；还必须勾选“覆盖按协议嗅探”，或者订阅本身提供了 sniff 表。否则可能出现嗅探器总开关开启、纯 IP 也开启，但核心实际上没有协议嗅探内容的情况。
HTTP 常见 80 和 8080，TLS 常见 443 和 8443，QUIC 常见 UDP 443，但现代应用并不只使用标准端口。范围太窄会漏，范围过宽会增加误判和 CPU 开销。普通用户使用订阅或 Nikki 默认值；只有确切应用使用非标准端口时再扩展。
4.36 追加规则 Provider
Rule Provider 是可以独立更新的大型规则集合。
- 类型
http从 URL 下载，file使用本地文件。 - URL 是规则地址，录视频时如果带私人令牌要打码。
- 下载节点决定更新规则时走 DIRECT 还是指定代理路径。
- 文件大小上限的输入单位是字节，零值通常代表不额外限制。在本视频核验的 Nikki 1.26.1 与 Mihomo
59ffb63中，页面生成size_limit，核心读取size-limit，因此该限制实际会被忽略，不能把它当作下载安全防线。 - 文件格式可选
mrs、yaml、text；必须与来源真实格式一致。 - Behavior 可选
classical、domain、ipcidr。Classical 可以包含多种经典规则；Domain 只放域名类；IPCIDR 只放地址网段。 - 更新间隔决定远程规则多久刷新一次，单位按 Mihomo 配置使用秒。
规则集名称必须唯一，并且后面的 RULE-SET 规则要引用同一个名字。来源不可信的规则集能够改变大量流量去向，不能只看“广告过滤数量多”就导入。
4.37 追加规则
每条规则包含启用、类型、匹配内容、目标节点或策略，以及部分 IP 规则可用的 no-resolve。虽然页面名称叫“追加规则”，Nikki 1.26.1 实际会把页面规则放在订阅规则前面，所以它们拥有更高优先级。
常见类型包括：
RULE-SET：引用前面定义的规则集。DOMAIN：精确域名。DOMAIN-SUFFIX：域名及其子域。DOMAIN-WILDCARD和DOMAIN-REGEX：通配或正则，灵活但开销和误匹配风险更高。DOMAIN-KEYWORD：域名包含关键词，容易误伤。IP-CIDR：目标 IP 网段。DST-PORT：目标端口。PROCESS-NAME：路由器本机进程名，对转发的手机 App 通常无效。GEOSITE和GEOIP：按 Geo 数据分类。
目标可以是 GLOBAL、DIRECT、REJECT、REJECT-DROP 或配置中存在的代理组。REJECT 主动拒绝，REJECT-DROP 静默丢弃；后者会让客户端等到超时，不一定比主动拒绝体验好。
no-resolve 用于 IP-CIDR、GEOIP 等规则，避免为了判断一条 IP 规则而额外把域名解析成 IP。它可以减少延迟和不必要的 DNS 查询，但如果这条规则必须依赖解析后的目标 IP，就不能盲目加。
最重要的是规则顺序：把精确规则放前面，宽泛规则放后面，最终兜底放最后。新增规则后要在面板中查看“命中规则”，不能只测试网页能打开。
4.38 GeoIP 格式与 GeoData Loader
GeoIP 格式可选 DAT 和 MMDB，必须与下载地址和配置引用方式一致。不是格式越新就一定越准，准确度取决于数据源维护质量。
Standard Loader 倾向于把数据加载到内存，匹配快但占用高；Memory Conservative Loader 更节省内存，首次或频繁查询可能更慢。PVE 上的 x86 OpenWrt 推荐 Standard；内存很小的软路由再考虑节省内存模式。
4.39 GeoSite、GeoIP MMDB、GeoIP DAT、GeoIP ASN URL
这四个 URL 分别提供域名分类、MMDB 地址库、DAT 地址库和 ASN 数据。只填写配置实际使用的格式，并选择可信、持续维护、适合所在地区的数据源。
数据源失效不会总是立刻让核心崩溃，更常见的表现是 Geo 规则更新失败或长期使用旧数据。排障时要同时看核心日志和文件更新时间。
4.40 GeoX 自动更新与更新间隔
自动更新让 Mihomo 定期刷新 Geo 数据，更新间隔按 Mihomo 的 geo-update-interval 使用小时。家庭网络可以开启，并设置例如 24 小时；频繁到每几分钟没有意义，反而增加下载失败和存储写入。
4.41 启用混入文件内容
这个开关会把编辑器中的“混入文件”加入最终合并，用来设置 UI 没有暴露的 Mihomo 字段。它是高级功能，也是最容易制造重复字段、类型冲突和缩进错误的地方。
推荐普通用户关闭。需要使用时，每次修改后都打开“检查配置文件”，并到编辑器查看最终“启动配置”，确认字段真的出现在预期位置。合并优先级是“订阅或本地配置文件，小于混入文件，小于 LuCI 混入选项”。混入文件还支持 nikki-proxies、nikki-proxy-groups、nikki-rules 三个特殊键，分别插到订阅原有的节点、代理组和规则列表前面。整套混入只在“仅核心”关闭时执行。不要直接修改启动配置，因为下一次重载会重新生成。
4.42 实机案例：页面看着“填了”，最终却没有生效
这台演示机正好能说明为什么必须查看启动配置。
第一，Fake-IP 过滤表里保存了 +.lan 和 +.local，但“覆盖 Fake-IP 过滤列表”没有开启，所以最终 YAML 没有这两项。
第二，DNS 表格里保存了阿里等解析器，但“覆盖 DNS 服务器”没有开启，所以运行时仍沿用订阅提供的腾讯、阿里、Cloudflare 和 Google DoH 策略。
这份订阅又没有显式提供 default-nameserver，因此核心会用内置的 114.114.114.114、223.5.5.5、8.8.8.8、1.0.0.1 做启动解析，主要用于解析 DoH/DoT 服务器自身域名，不是所有客户端域名的主查询。做 DNS 隐私科普时要把“启动 DNS”和“主查询 DNS”分开讲。
第三，嗅探器总开关和纯 IP 嗅探虽然开启，但“覆盖按协议嗅探”未开启，订阅又没有提供 HTTP、TLS、QUIC 的 sniff 表，所以最终嗅探配置实际上缺少协议内容。
这不是 Nikki 出错，而是“表格数据”和“是否注入”的设计。录视频时打开编辑器里的启动配置，对照这三处展示，观众会立刻理解“不修改”和“覆盖”的区别。
第五章：代理配置——OpenWrt 到底抓哪些流量
5.1 代理配置总开关
这里的“启用”是 Nikki 透明代理管理总开关。关闭后 Mihomo 核心仍可能运行，手动 HTTP/SOCKS 代理也可能可用，但 Nikki 不会按这一页建立透明接管规则。
推荐主路由或旁路网关透明代理开启。它和插件配置最上面的服务“启用”缺一不可。
5.2 TCP 模式：Redirect、TPROXY、TUN
Redirect 使用 nftables NAT 把 TCP 连接重定向到 Mihomo 的 Redir 入口。它结构简单、性能好，适合绝大多数 TCP 流量，但只处理 TCP。
TPROXY 使用透明代理标记和策略路由，可以保留原目标信息，并同时适用于 TCP、UDP。它依赖内核模块、策略路由和更复杂的防火墙链，配置冲突时排障难度更高。
TUN 把被标记流量路由到虚拟网卡，由 Mihomo 网络栈处理。兼容协议范围广，尤其适合 UDP 和复杂 IPv6，但多一层用户态网络处理，资源开销通常更高。
推荐起点：TCP 使用 Redirect，UDP 使用 TUN。这是性能和兼容性的折中。遇到特殊 TCP 或需要统一 TUN 行为时，可以测试 TCP、UDP 都用 TUN；熟悉策略路由并需要保留透明目标时再用 TPROXY。
5.3 UDP 模式：TPROXY 与 TUN
UDP 没有 Redirect 模式，只能选择 TPROXY 或 TUN。游戏、QUIC、语音、DNS 都大量使用 UDP，所以不设置 UDP 模式并不只是“游戏不代理”，还可能让 HTTP/3 和部分 DNS 直接绕过。
推荐普通用户使用 TUN。若设备性能有限、内核 TPROXY 支持完整并且已有成熟规则，也可以选择 TPROXY。切换后要测试 QUIC、语音和 IPv6 UDP，而不是只打开一个 TCP 网页。
5.4 IPv4/IPv6 DNS 劫持
DNS 劫持把客户端发往任意传统 TCP/UDP 53 端口的查询重定向到 Mihomo DNS 监听端口。它可以阻止设备把 DNS 手动写成 8.8.8.8 后绕过路由器，但不能拦截应用内置的 DoH、DoT 或 DoQ；那些是 443、853 等普通加密连接，需要靠透明代理和规则处理。
双栈网络必须同时开启 IPv4 和 IPv6 DNS 劫持。只抓 IPv4 时，手机可以通过公网 IPv6 向外部 DNS 查询，测试网站就可能显示运营商 IPv6 DNS。
推荐：Fake-IP 场景两项都开启。前提是混入配置里 DNS 已启用并监听正确端口。
5.5 IPv4/IPv6 代理
这两个开关决定透明代理规则处理哪种网络层协议。启用混入配置的 IPv6，只代表核心会处理 IPv6；代理配置里的 IPv6 代理不开，LAN 的公网 IPv6 仍可能直接从 WAN 出去。
双栈网络推荐 IPv4、IPv6 都开启。只有明确不提供 IPv6、并且 LAN 也不下发 IPv6 默认路由时才关闭 IPv6。开启以后如果国外 IPv6 仍显示本地出口，要检查 LAN 访问控制是否只写了 IPv4 地址。
5.6 Fake-IP Ping 劫持
Fake-IP Ping 劫持针对 198.18.0.0/16 这类假地址的 ICMP Echo。开启后，发往假 IP 的 echo-request 会被 nftables 重定向，由路由器本地接住并回复；它不会进入 Mihomo/TUN 再去 ping 真实服务器。
Fake-IP 模式推荐开启；Redir-Host 模式没有必要。它只改善假 IP 的 ping 行为，不代表真实服务器一定允许 ICMP，也不能把 ping 延迟当作节点实际延迟。
5.7 路由器代理
“路由器代理”处理 OpenWrt 本机发起的流量，例如软件更新、curl、NTP、路由器插件及部分 host-network 本机服务。它与“局域网代理”不同：后者处理从 LAN 转发来的手机和电脑流量。Docker bridge、macvlan 或独立 network namespace 的容器不一定属于本机 output 链，必须按容器网络模式和实际入站接口单独核对。
推荐开启，但保留 Nikki 默认的系统服务排除项，尤其是 dnsmasq、Mihomo 自身和可能参与网络启动的服务，避免 DNS 或代理回环。
5.8 路由器访问控制：用户、组、CGroup、DNS、代理
路由器访问控制可以按 Linux 用户 UID、组 GID 和服务 CGroup 匹配本机进程。DNS 勾选表示该对象的 53 端口查询进入 Mihomo，代理勾选表示它的普通流量进入透明代理；不勾则在这一行直接返回、绕过对应处理。
这些匹配在同一行更接近“任意一个命中即可”，不是必须同时满足用户、组和 CGroup。规则按顺序执行，所以具体排除放上面，最后再放无条件的兜底规则。
普通用户不要删除 Nikki 默认对 dnsmasq、Nikki 自身等服务的保护。把 dnsmasq 一边劫持到 Mihomo、又让 Mihomo 的启动解析回到 dnsmasq，是最常见的 DNS 死循环之一。
5.9 局域网代理与入站接口
“局域网代理”是 LAN 设备透明接管总开关。“入站接口”选择流量从哪个 OpenWrt 逻辑网络进入，例如 lan、访客网络或单独 VLAN。
如果 LAN 的 IPv4 和 IPv6 都在同一张 br-lan 或 eth0 上，只选 lan 就能处理双栈，不需要因为有 IPv6 再机械地选择一个同设备的 LAN6。只有 IPv6、访客网或 IoT 网确实使用不同接口或 VLAN 时，才额外选择。
不要选择 WAN 作为 LAN 入站接口，否则可能把外部流量送进不该使用的透明代理链。
5.10 LAN 访问控制：IP、IPv6、MAC
访问控制每一行可以按 IPv4、IPv6 或 MAC 匹配，并分别决定 DNS 和普通代理是否接管。
这里有一个非常关键的坑：如果一行只填写 192.168.1.88，生成的规则只匹配这台设备的 IPv4。手机的公网 IPv6 和临时 IPv6不会自动继承这条规则，于是 IPv4 走代理、IPv6 直连，形成看似神秘的 IPv6 泄漏。
要同时覆盖一台设备的 IPv4 和 IPv6，优先使用 MAC。手机开启“每个 Wi-Fi 使用随机 MAC”时，这个 MAC 通常在当前 SSID 内稳定；如果重置随机地址，规则也要更新。不要把手机不断变化的隐私 IPv6逐条填进去。MAC 匹配适用于以太网或 Wi-Fi 进入的 LAN 流量；PPP、某些 VPN 等没有以太网头的接口不能依赖 MAC。
同一行里的 IP、IPv6、MAC 是“任意一个命中”，不是三者必须同时满足；路由器访问控制里的用户、组和 CGroup 也是类似的“或”关系。
规则顺序同样重要：具体设备放上面，无条件兜底放最后。左侧“启用”必须勾选，否则这一整行只是保存在页面里，不会生成规则。
5.11 全 LAN 接管，同时排除一台直连设备
最实用的组合是两行：
第一行填写需要直连设备的 MAC，启用这一行，但 DNS 和代理都不勾。第二行 IP、IPv6、MAC 全留空，启用这一行，并同时勾选 DNS 和代理。具体排除在上，全 LAN 兜底在下。
第 1 行：启用 + 指定 MAC + DNS 关 + 代理关
第 2 行：启用 + 条件全空 + DNS 开 + 代理开这表示第一台设备绕过 Nikki、直接使用运营商网络，不是“禁止它上网”。如果设备只能访问局域网、完全不允许访问互联网，还要在 OpenWrt 防火墙按 MAC 拒绝它前往 WAN/WAN6。
还有一个 Fake-IP 注意事项：一台设备如果“代理关闭、DNS开启”，它可能从 Mihomo 拿到假 IP，却又不把连接送入 Mihomo，结果就是网站打不开。因此完全直连的排除设备通常 DNS 和代理都关闭。
5.12 绕过中国大陆 IPv4/IPv6
开启后，Nikki 会在进入 Mihomo 之前，根据本地 GeoIP 集合直接放行中国大陆目标地址。好处是减少核心连接数和 CPU 开销；坏处是这些连接不会再经过 Mihomo 的域名规则、嗅探、面板统计和更细的策略组。
它是防火墙级 IP 粗分流，不等同于订阅里的“国内服务 DIRECT”。如果你的订阅规则已经完善，推荐两项都关闭，让国内流量先进入 Mihomo，再由规则明确选择 DIRECT。性能很弱的设备、并且接受纯 IP 分流时才开启。
开启 IPv4 却漏开 IPv6，会让同一国内服务的 A 记录和 AAAA 记录走不同路径；真要使用这个功能应保持双栈策略一致。
5.13 要代理的 TCP/UDP 目标端口
这里决定哪些目标端口进入透明代理。“全部端口”就是 0-65535；“常用端口”预设 TCP 为 21 22 80 110 143 194 443 465 853 993 995 8080 8443，UDP 为 123 443 8443，其他端口直接绕过。传统 DNS 53 不在这组端口里，而是由前面的 DNS 劫持独立处理；TCP 853 属于加密 DNS 等用途。
全 LAN 接管推荐 TCP、UDP 都选全部端口。只选常用端口看似省资源，实际上游戏、远程桌面、Cloudflare Tunnel、自定义服务和新协议很容易从非标准端口绕过。只有明确要做端口白名单分流时才缩小范围。
5.14 绕过 DSCP
DSCP 是 IP 包头中的六位服务质量标记，通常给 QoS 和业务优先级使用。把某个值加入“绕过 DSCP”后，普通目标中携带该值的 IPv4 和 IPv6 数据包会在进入代理前直接返回。Nikki 对 IPv4 Fake-IP 目标有例外：即使 DSCP 命中，也仍会送入核心，避免假地址被拿去直连；配置 Fake-IP6 时 IPv6 也有对应保护。
Nikki 1.26.1 出厂默认可能预置 4，所以看到它不代表配置异常。它表示 DSCP 值为 4 的流量拥有一条绕过通道。普通用户保留默认通常不会有问题；如果目标是严格不保留任何隐含旁路，并且没有自己的 nftables/QoS 规则使用 DSCP 4，可以清空。DSCP 合法范围是 0 到 63。
5.15 绕过 FWMark
FWMark 是 Linux 内核给数据包附加的内部标记，不会像 DSCP 一样发送到公网。WireGuard、Tailscale、多 WAN、策略路由和其他代理可能使用它。把标记加入绕过列表，可以防止某类流量被 Nikki 再次代理，避免回环。
普通用户留空。不要照抄别人的十六进制值，因为相同数字在不同路由器上可能属于完全不同的服务。FWMark 绕过没有前面 DSCP 对 Fake-IP 的特殊保护，设置错了不仅会让一大批流量无声直连，还可能让假 IP 连接直接失败。高级格式可带掩码，例如 0x3F00/0xFF00，不理解 mark/mask 判断就不要填写。
5.16 IPv4/IPv6 保留地址
保留地址是目标属于这些网段时不进入代理、直接由本地路由处理。默认列表包括：
- IPv4 私网
10/8、172.16/12、192.168/16； - 回环
127/8、链路本地169.254/16； - CGNAT 与 Tailscale 常用的
100.64/10； - 组播和其他特殊用途网段；
- IPv6 回环、ULA、链路本地、组播、NAT64 及文档或兼容用途网段。
这些默认值保证路由器后台、NAS、打印机、局域网发现和隧道内网不会被错误送到公网节点，建议完整保留。
不要添加 0.0.0.0/0 或 ::/0，那等于绕过全部流量；不要把运营商公网 IPv6 前缀加进去；也不要把 Fake-IP 的 198.18.0.0/16 加入保留地址。Nikki 的规则会对 Fake-IP 做特殊处理，手工扩大保留范围容易破坏它。
还有一个全局顺序需要知道：传统 TCP/UDP 53 的 DNS 劫持先执行；普通数据流随后才依次检查本地/回复流量、保留地址、中国 IP、目标端口、DSCP、FWMark，最后进入设备访问控制。因此“空条件全 LAN 接管”也不能反过来覆盖前面的全局绕过条件，但保留地址和端口选择不会阻止已经启用的 53 端口 DNS 劫持。
5.17 TUN 等待超时与检查间隔
TUN Timeout 不是网页连接超时，而是 Nikki 启动核心后，最多等多少秒让 TUN 设备上线。TUN Interval 是等待期间每隔多少秒检查一次。
推荐使用默认的 30 秒和 1 秒。核心正常时会很快上线，并不会每次真的等待 30 秒。只有低性能设备加载大型配置确实超过 30 秒时才增加 Timeout。Interval 绝对不要填写 0，否则启动脚本可能无法正常递减超时并形成忙等；保持 1 秒即可。
第六章：面板、日志和验证
6.1 面板里的连接为什么很多只显示 IP
面板中的 IP:端口 是当前被 Mihomo 看到的连接，不代表外部在攻击路由器。IPv6 地址必须写成 [IPv6]:443，方括号只是为了把地址和端口分开。
只显示 IP、不显示域名，常见原因是应用直接连接 IP、使用 QUIC/UDP、DNS 映射已失效，或者嗅探器无法从加密握手恢复域名。443 通常是 HTTPS 或 QUIC，80 是 HTTP，自定义端口则要结合“来源 IP、Host、命中规则、连接链”判断，不能只靠端口猜应用。
如果一条客户端 IPv6 连接能出现在 Mihomo 面板里，并显示命中 cn → DIRECT，只能证明这一条连接已经进入 Mihomo，并由规则主动选择直连，所以这条本身不是“漏抓”。它不能证明该设备所有 IPv6、UDP、53、DoH 和其他端口都无旁路；ACL、端口范围、DSCP 和 FWMark 仍可能造成选择性绕过，完整性还要按后面的验证顺序检查。
6.2 插件日志、核心日志和日志级别
插件日志记录订阅下载、混入、配置检查、TUN 等待、策略路由和 nftables 创建过程。核心日志记录 Mihomo 自身的 DNS、节点、provider、规则和连接错误。
核心不启动，先看插件日志是否停在订阅、混入或配置检查；核心启动但网站打不开，再看核心日志和面板命中规则。不要只截一张“无法连接”的浏览器页面。
“清空日志”会立即截断当前日志，无法恢复；“滚动到底部”只是移动网页文本框，不会改变日志文件。准备排障时先下载或复制日志，再执行清空。
6.3 停止时清空、定时清空、Cron 和大小限制
“停止时清空”会在停止、重载和重启清理阶段截断日志。日常可以开，排障时一定关，否则刚重启完，最有价值的错误证据也没了。
“定时清空”按照 Cron 周期检查日志大小；达到“大小上限”后会把整份日志清零，不是保留最后若干 MB 的滚动日志。单位可以选 KB、MB 或 GB。
推荐开启定时清理，例如每 5 分钟检查一次、上限 1 到 5 MB。Nikki 日志通常位于 tmpfs，占用的是内存，路由器重启后也会消失。
6.4 生成调试日志
调试日志会收集系统版本、Nikki/UCI 配置、运行配置、策略路由、nftables 和 procd 状态，用于向开发者报告问题；它并不包含 app.log 和 core.log 的正文，核心报错仍要单独复制。脚本会遮盖一部分常见密码和订阅 URL，但不能保证识别所有自定义密钥。
还有一个容易忽略的副作用：如果 Nikki 当时处于禁用状态，生成调试日志的脚本会临时启用并重启 Nikki，采集后再禁用并再次重启。生产网络执行前要预留短暂连接中断。
分享之前必须人工检查，至少搜索 url、token、secret、password、UUID、公网地址和节点名称。不要把调试包原样上传到公开群或视频简介。
6.5 一套可靠的验证顺序
改完配置不要只测一次 IP。建议按这个顺序：
- 插件日志确认配置检查通过、TUN 在线、Hijack successful。
- 面板确认手机或电脑的 IPv4 来源连接能出现。
- 面板确认同一设备的公网 IPv6 来源连接也能出现。
- 分别访问国内和国外站点，核对命中的是 DIRECT 还是预期代理组。
- 测试 UDP/QUIC、普通 TCP、DNS 和局域网设备访问。
- 最后再做 DNS 泄漏和出口 IP 测试，并区分“规则主动直连”与“没有进入 Mihomo”。
DNS 泄漏测试显示一个解析器，并不自动等于泄漏。关键是这个解析器是否属于你配置的上游、查询是否按预期走代理，以及客户端是否能绕过劫持直接请求另一个 DNS。
以这台 OpenWrt 为例，最终链路可以在系统里直接验证：TCP 被 Redirect 到 7891；TCP/UDP 53 被重定向到 Mihomo DNS 的 1053；UDP 被打上 0x81 标记，经优先级 1025、路由表 81 送入 nikki TUN；IPv4 和 IPv6 都存在对应策略路由。比起只截一张出口 IP，这类“入口端口、标记、路由表和规则计数都在命中”的证据更能证明接管完整。
第七章：三套可以直接给观众的配置思路
7.1 双栈 Fake-IP、全 LAN 接管的推荐起点
如果你是 PVE 里的 x86 OpenWrt，作为主路由或实际网关，想要 Fake-IP、IPv4/IPv6 双栈和全 LAN 接管，可以从下面这组设置开始：
插件配置
启用：开
检查配置文件：开
仅核心：关
定时重启：关
快速重载：关
nofile 软/硬限制：65536 / 65536
混入 / 全局
日志：warning
模式：rule
匹配进程：off
出站接口：不修改
IPv6：开
统一延迟：开
TCP 并发：开
TCP Keep Alive：不修改，不禁用
混入 / TUN
启用：开
设备名：nikki
栈：Mixed
MTU、GSO：先保持默认
覆盖 TUN DNS 劫持：关
混入 / DNS
启用：开
缓存：ARC
监听：[::]:1053
IPv6：开
模式：Fake-IP
IPv4 地址池：198.18.0.1/16
Fake-IP 缓存：开
代理配置
启用：开
TCP：Redirect
UDP：TUN
IPv4/IPv6 DNS 劫持：都开
IPv4/IPv6 代理：都开
Fake-IP Ping 劫持：开
局域网代理
启用：开
入站接口：lan
最后一条访问控制：条件全空，DNS 和代理都开
绕过
绕过中国大陆 IPv4/IPv6：关
TCP/UDP 目标端口：全部
DSCP：可保留 1.26.1 默认的 4；严格无旁路且未使用 QoS 时可清空
FWMark：留空
保留地址：保持默认这不是所有网络的唯一答案，而是一套逻辑闭环的起点：DNS 先进入 Mihomo，Fake-IP 映射存在，IPv4 和 IPv6 都被 LAN 规则抓取，TCP 和 UDP 也都有处理路径。
7.2 全 LAN 接管，但一台设备直连
不要再用固定 IPv4 排除双栈手机。用 MAC 建第一条排除规则，DNS 和代理都关；再用第二条空条件规则接管其余设备。排除规则一定在上面，两条左侧都要启用。
如果那台设备不是“直连”，而是“完全禁止上网”，Nikki 排除不负责安全隔离，必须另加 OpenWrt 防火墙规则同时阻止 WAN 和 WAN6。
7.3 低内存设备怎么减负
低内存不是把 IPv6、DNS 劫持和 UDP 随便关掉。正确的减负顺序是：日志保持 warning；DNS 缓存改 LRU；GeoData Loader 选择 Memory Conservative；减少不必要的超大型规则集；确认兼容后测试 System TUN 栈；关闭不使用的面板和手动代理入站。
不要给 Go 堆随便写一个极低的 GOMEMLIMIT，也不要把 nofile 降得很小。那会把“资源节省”变成频繁 GC 和随机连接失败。
第八章：保存、应用和出问题时怎么回退
“保存”通常只把页面值写入待应用配置；“保存并应用”会提交并触发服务处理。改了监听端口、TUN、代理模式、IPv6 接管或访问控制后，建议保存并完整重启一次。
页面上的“复位”通常只是丢弃尚未保存的表单变化，不是恢复出厂设置，也不能撤销已经保存并应用的配置。修改前应备份 /etc/config/nikki、本地 YAML 和混入文件。
一次只改一组相关选项。比如先改 LAN 访问控制并验证双栈，再改 DNS；不要同时切换 TUN 栈、DNS 模式、Geo 数据和全部规则，否则出问题时无法判断是哪一项造成的。
最小回退顺序是：保留订阅文件，关闭新加的覆盖开关，恢复默认保留地址和全部端口，恢复 DSCP 默认、清空 FWMark 绕过，恢复 TCP Redirect 加 UDP TUN，然后重启。仍失败时查看“启动配置”和两类日志，而不是连续点击复位。如果透明接管导致 LuCI 无法正常操作，但 SSH 仍可连接，可以先执行 /etc/init.d/nikki stop 清理 Nikki 接管规则，再恢复备份；这属于应急回退，会让设备暂时直连。
结尾
最后总结三个最重要的判断。
第一，“不修改”不是关闭，而是让订阅或核心默认值决定。
第二，混入配置负责 Mihomo 怎么处理，代理配置负责 OpenWrt 把什么流量送进去；只开其中一边，尤其容易产生 IPv6 和 DNS 绕过。
第三，面板里的 DIRECT 是一条明确命中的规则，不等于泄漏；真正的泄漏往往根本不会出现在面板连接列表里。
理解这三点以后，Nikki 就不再是一页需要照抄的开关，而是一套可以验证、可以排障的透明代理系统。
配置自查清单
核心运行中 ≠ 透明代理已接管
仅核心：全 LAN 透明代理用户不要开
Fake-IP：DNS 必须进入 Mihomo
双栈：IPv6 DNS 劫持 + IPv6 代理都要开
按设备控制：优先 MAC，不要只写 IPv4
全 LAN：空条件兜底规则必须启用
直连设备：DNS 与代理一起排除
中国 IP 绕过：是防火墙粗分流，不是核心规则分流
DSCP：默认 4 可保留；严格无旁路且不用 QoS 时再清空
FWMark：不懂就留空
保留地址：默认保留，别加 0.0.0.0/0 或 ::/0
出现问题：看插件日志、核心日志、启动配置和面板命中规则