一、一句话说清 UA2F 在做什么

在路由器的转发路径上，UA2F 把经过它的 HTTP 请求里的 User-Agent 字段统一改写，让内网里不同设备（手机、电脑、电视盒子）看起来像同一台设备发出的流量。它针对的是"基于 User-Agent 的设备指纹识别"——当网络侧用 UA 判断"这是不是违规共享、是不是多设备"时，把 UA 抹平就是最直接的反识别手段。

关键不在于"改什么"，而在于"怎么改"：UA2F 不碰应用层代理、不解密 HTTPS，而是借助 **NFQUEUE 机制**，在报文还停在防火墙队列里、尚未被转发出去时拦下来改掉，再放回去。理解 NFQUEUE，就理解了 UA2F 的全部原理。

二、NFQUEUE：让内核把包"递"给用户态程序

netfilter（iptables/nftables 的内核引擎）里有一类 target 叫 NFQUEUE。它的作用是：把匹配到的数据包从内核态交给用户态程序处理，处理完再由程序决定丢弃、放行还是修改后重新入队。

UA2F 依赖的正是这条通道。防火墙规则命中目标包后，不立即走正常转发，而是扔进一个编号队列（queue-num，常见 10010）；UA2F 通过 libnetfilter_queue 取包、改包、再 verdict 回去。两个细节决定了它为什么"稳"：

• --queue-bypass 兜底：如果用户态程序挂了、没来取包，带 bypass 的队列会让包直接按原路径放行，而不是全部卡死——最多不改写，不会把整网掐断。
• 内核与用户态的拷贝开销：每包一次上下文切换和数据拷贝是有成本的，这正是 UA2F 要把"要处理的包"缩到最小范围的根本动机。

三、防火墙规则骨架：先把"哪些包要拦"定清楚

UA2F 自动安装的 netfilter 规则（mangle 表）大致长这样（简化示意）：

iptables -t mangle -N ua2f
iptables -t mangle -A ua2f -d 10.0.0.0/8     -j RETURN   # 不处理保留地址
iptables -t mangle -A ua2f -d 127.0.0.0/8     -j RETURN
iptables -t mangle -A ua2f -d 192.168.0.0/16  -j RETURN
iptables -t mangle -A ua2f -p tcp --dport 443 -j RETURN   # 不处理 HTTPS
iptables -t mangle -A ua2f -p tcp --dport 22  -j RETURN   # 不处理 SSH
iptables -t mangle -A ua2f -p tcp --dport 80  -j NFQUEUE --queue-num 10010
iptables -t mangle -A FORWARD -p tcp -j ua2f

逻辑非常克制：先排除保留地址、排除 443/22 这类不该动的流量，只对目标端口 80 的 TCP 包进 NFQUEUE。这就是"只拦 80 端口"的由来。

四、为什么只拦 80 端口（HTTP）

因为 User-Agent 只在明文 HTTP 里看得到，而 80 端口承载的正是未加密的 HTTP。

80 = HTTP = 明文请求行、各种头部（含 UA）都是明文，UA2F 能直接读、直接改。
443 = HTTPS = 加密TLS 握手后应用层内容被加密，路由器拿不到明文，规则里直接 RETURN 放行。
22 / 其他与 UA 改写无关，直接放行，避免无谓的 NFQUEUE 开销。

这是一个"能改的才改、改不了的放过去"的边界决策，也决定了 UA2F 的能力上限：它只在 HTTP 世界里有效。如今网站普遍强制 HTTPS，这也是它被视作"早期方案"的原因（见第八节）。

五、为什么只改"首包"

全篇最有信息量的问题，答案分两层：改得动和改够用。

5.1 改得动：UA 就在第一个 TCP 段里

TCP 三次握手之后，客户端第一个携带数据的 TCP 报文，通常就包含了完整的 HTTP 请求起始行和头部。因为请求行 + 请求头（含 UA）整体不大，而一个 TCP 段约能装 MSS（默认 1460 字节）数据，正常情况下它们都落在同一个首包里。所以 UA2F 判断一个包是不是 HTTP 请求，方法很朴素：看它是否以 HTTP 方法开头（GET、POST 等）。是，就解析头部找 UA；不是，直接放走。

5.2 改够用：UA 是请求方属性，且只需等量替换

User-Agent 是客户端在请求头里主动声明的字段，整个会话只有请求方有，服务端响应里没有。只要把客户端第一个请求里的 UA 改掉，这一整条连接的服务端视角就已经被"骗"过去了——不需要、也没法改响应方向。

一句话记忆点：UA 在首包、改首包就够；等量替换让首包改完"天衣无缝"，无需追踪整条连接——长度不变，TCP 序号和校验和都不必重算，服务端回的 ACK 依然对得上。

六、改包的完整流程

进 FORWARD 链报文命中 ua2f 规则。
分流保留地址 / 443 / 22 直接 RETURN；80 端口进 NFQUEUE。
取包判定UA2F 用户态进程从队列取包，判断是否以 HTTP 方法开头。
找 UA 字段是的话向下解析头部，定位 User-Agent:。
等量替换换成长度相同的新 UA，重算 IP/TCP 校验和（序号不动）。
verdict 回内核包继续正常转发，服务端收到改写后的 UA。

七、性能优化：把"要拦的包"再缩一圈

NFQUEUE 每包都有内核↔用户态开销，所以 UA2F 用连接跟踪进一步减少进队列的包：

• CONNMARK 标记：一条连接首次判定为"非 HTTP"后打上连接标记，后续包直接跳过 NFQUEUE。社区资料称可减少 80% 以上负载。
• ipset nohttp：把"非 HTTP 目标 IP:端口"临时记进 ipset（带超时），同目标后续连接直接 RETURN，连首包判定都省。
• disable_connmark 开关：关闭后降低性能，但能避免和别的也改 Connmark 的程序冲突。

这些优化都指向同一件事：能不进 NFQUEUE 的包，一个都别进。

八、三种运行模式：NFQUEUE / REDIRECT / TPROXY

模式	机制	适用	注意
NFQUEUE（默认）	netfilter 队列直接改写 TCP 包本体	保留原有行为，最通用	在转发路径上直接改包
REDIRECT	透明代理，流量引到本地端口，UA2F 再连原目标	处理本机 OUTPUT 流量	需要本地监听端口
TPROXY	透明代理，适合接管转发流量	转发流量接管	需策略路由把 fwmark 指向 lo；不动本机 OUTPUT

一个易踩的坑：TPROXY 固定监听端口的透明代理不处理本机自己的 OUTPUT 流量，本机流量得用 REDIRECT 或 NFQUEUE；同时 UA2F 自己出站连接会打 SO_MARK，防火墙规则要 bypass 这个 mark，否则改写后的连接又被同一套规则抓回，形成回环。

九、边界与局限：它到底能管到哪

把能力边界讲清楚，比把工具吹万能更有价值：

• 只覆盖明文 HTTP：HTTPS 里的 UA 看不到、改不了，这是 80 端口路线的硬天花板。
• 挡不住 DPI：深度包检测分析 TLS 指纹、包长、时序等，只改 UA 基本无效。
• 可能与硬件加速冲突：MT7621 的 HW NAT、高通 NSS 会在 UA2F 介入前快速转发，导致改写不生效。
• 与代理软件同用易出问题：透明代理、VPN 叠加时报文路径变复杂，规则互相干扰。
• 演进方向：HTTPS 普及后，社区出现处理 TLS 层（SNI/指纹伪装、TTL 统一）的后续方案，但已超出"HTTP 首包改 UA"范畴。

十、自查清单

• 已确认 OpenWrt 版本与 UA2F 包架构匹配（如 aarch64_cortex-a53）
• 依赖已装：iptables-mod-nfqueue、libnetfilter-queue 等
• 防火墙规则确认只对 80 端口进 NFQUEUE，443/22/保留地址已放走
• custom_ua 长度与原 UA 接近（等量替换避免序号/校验和异常）
• 评估是否需关闭 HW NAT / NSS 硬件加速以让改写生效
• 已用公开 UA 检测页验证路由器出口 UA 是否被改写
• 了解局限：HTTPS 流量不生效、DPI 场景下无效

十一、常见问题（FAQ）

Q1：为什么 UA2F 不能改 HTTPS 里的 UA？

443 端口走 TLS 加密，转发路径上的路由器只能看到密文，拿不到应用层 HTTP 头部，无法改写 User-Agent。规则对 443 直接放行就是这个原因。

Q2：既然只改首包，一个网页后续加载的资源不改吗？

HTTP/1.1 下每个资源通常是独立 TCP 连接（或复用连接的独立请求），它们的请求头同样以首包形式发出，每一条连接的"请求首包"都会被 UA2F 处理。本质是"每条连接的请求首包都改"，不是"整站只改一次"。

Q3：等量替换怎么做到？长度必须一模一样吗？

UA2F 把自定义 UA 截断/填充到与原 UA 相同的字节长度（运行时取长度匹配的子串）。长度不变，TCP 序号和校验和都无需重算，包才能"无缝"放回队列。

Q4：NFQUEUE 模式程序挂了会断网吗？

默认带 --queue-bypass 时不会。程序不取包，包就按原路径直接放行，最多不改写，不会掐断网络。这是"宁可失效也不雪崩"的兜底。

Q5：CONNMARK 和 ipset 是干什么的？

都是为了减少进 NFQUEUE 的包、降低开销。CONNMARK 标记"非 HTTP 连接"整条跳过；ipset 把"非 HTTP 目标"缓存一段时间，连首包判定都省。两者都把"能不进队列的包"挡在门外。

Q6：为什么某些路由器上改了没效果？

最常见原因是硬件转发加速（HW NAT / NSS）在 UA2F 介入前就快速转走了包。需要在路由器设置里关闭对应加速，或确认流量确实经过了 mangle 表的 ua2f 链。

Q7：TPROXY 和 REDIRECT 怎么选？

转发流量适合 TPROXY（需策略路由配合）；本机 OUTPUT 流量 TPROXY 不处理，得用 REDIRECT 或 NFQUEUE。叠加配置时要避开 UA2F 自身出站连接的回环（bypass 它的 SO_MARK）。

Q8：UA2F 现在还值得用吗？

若场景里仍有明文 HTTP、识别手段只停留在 UA 层面，它依然轻量有效。但网络侧已上 DPI 或全面 HTTPS 时，单靠 UA2F 作用有限，需要更复杂的 TLS 层伪装方案。

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务，全网第一款指纹识别技术防火墙，自研的WAF指纹识别架构，提供任意CC和DDoS攻击防御