核心分析¶

项目定位：zapret 专注于解决“DPI 基于流/包特征识别并触发阻断/限速，导致特定站点或协议不可用”的问题。它不是 VPN 或远端代理，而是在本地通过有控的包/流修改来避免 DPI 触发。

技术分析¶

• 为什么能解决问题：DPI 依赖于特征签名与流重组；通过在数据平面引入非典型分段、篡改 TCP 序号、注入伪包或修改 HTTP 头等手段，zapret 将流的表征改变为 DPI 无法或难以匹配的形式，从而避免触发阻断。
• 工具维度：nfqws 在 NFQUEUE 层做包级修改，能在重组前拦截；tpws 在流层做透明代理式分段/改写，适合需要保留连接语义的场景。两者可按成本/兼容性组合使用。

实用建议¶

1. 小范围验证：先在测试设备上以 dry-run 模式和少量目标 hostlist 验证策略效果。
2. 限定范围：使用 autohostlist 或自定义 hostlist 仅对受影响流量生效，避免全局干预。
3. 选型：CPU/内存充足时优先 nfqws 获取更细粒度控制；资源受限时优先 tpws 或精简策略。

重要提示：当目标为被直接按 IP 封锁或 DPI 具有完整流重组并能重新发起连接时（如某些中间代理），该方法无效。

总结：zapret 的核心价值是为本地设备提供一套可配置的脱同步与伪造工具，针对以特征/重组为基础的 DPI 提供实用的绕过路径，但不是针对所有封锁场景的万能解。

核心分析¶

选择动因：采用 NFQUEUE 与原始套接字/流改写，是为了在 内核/用户态交界 获取对数据包与流的直接控制，从而在 DPI 完成重组或签名匹配之前破坏其输入特征。

技术特点与优势¶

• 细粒度干预（包级）：nfqws 使用 NFQUEUE 将数据包转到用户态，能在 TCP 重组前修改序号、分段或伪造包；这对那些在重组前进行轻量匹配的 DPI 极为有效。
• 流级兼容（代理式）：tpws 在连接层处理数据，通过透明代理式改写实现更复杂的语义变换（例如按应用层规则拆分请求），在某些设备上性能更友好且兼容性更高。
• 模块化与可组合：不同策略可在这两个层级组合使用，按场景取舍精度与性能。
• 可移植与轻量化考量：工具设计考虑嵌入式路由器（OpenWrt），说明实现注重减小运行时开销与依赖。

实用建议¶

1. 优先策略：资源允许时优先 nfqws（精度高）；在 CPU 受限或需要更好连接语义时使用 tpws。
2. 混合使用：对同一目标先用 tpws 做低开销尝试，必要时升级到 nfqws 做包级干预。
3. 监控成本：在部署前监测 CPU、conntrack 条目与延迟，避免因 NFQUEUE 阻塞导致全局网络退化。

重要提示：NFQUEUE 持久高负载可能导致内核队列阻塞，出现丢包或连通性问题；务必配置合理队列长度并测试压力场景。

总结：NFQUEUE 与流改写的组合在控制精度与实际可部署性之间提供了必要的权衡，使得项目既能进行细粒度干预又能在嵌入式环境下运行。

核心分析¶

学习成本：中高。需要理解 iptables/nftables、NFQUEUE、conntrack、TCP 序号与重组、以及如何在资源受限设备上监测 CPU 与连接表。对新手来说，这些概念是主要障碍。

常见陷阱¶

• 规则误配置导致网络中断：不当的 NFQUEUE 或 iptables 规则可能拦截并阻塞大部分流量。
• 策略破坏合法连接：错误的分段/序号覆盖会使 HTTP/HTTPS 会话失败或 TLS 握手被干扰。
• 性能瓶颈：在高并发或高带宽下包级修改对 CPU 消耗大，嵌入式设备可能无法承受。

实用建议（最小化风险）¶

1. 逐步验证：在测试机或隔离环境启用 dry-run 或低影响模式，观察目标站点是否恢复或出现异常。
2. 限定作用域：只对必要的 hostlist / IP 列表启用策略，避免全局生效。
3. 回退与监控：部署时保留一键禁用脚本或 systemd 单元，监控 CPU、conntrack、延迟与连接失败率。
4. 配置备份：在修改 iptables/nftables 前保存当前规则，确保快速回滚。
5. 阶梯升级：先用低开销策略（如 HTTP 头微调、简单分段），再根据效果启用更侵入的包级策略。

重要提示：在生产网络上首次部署前务必准备回滚计划，以防出现全局连通性问题。

总结：通过保守、分步骤的测试与严格的回退策略，可以将 zapret 的运维风险控制在可接受范围，并逐步积累调参经验。

核心分析¶

典型无效场景：

• 按 IP 直接封锁：若目标 IP 在网络层被丢弃或路由不可达，包级或流级改写不会改变可达性。
• 中间代理/完全重组的 DPI：如果 DPI 在链路中间能完整重组会话并以重建后的语义判断（或直接在服务端一侧发起连接），本地的脱同步/伪造无法改变其判断。
• 端到端证书/握手替换：当中间盒子重写 TLS 会话或在应用层做完整重建，轻量级包改写难以奏效。

如何评估不可行性¶

1. IP 可达性检测：使用 ping、traceroute、多端点 telnet 到端口，判断是否存在 IP 层丢包或黑洞。
2. 注入/重置行为观测：用抓包工具（tcpdump）观察是否有来自中间网元同时发向 server & client 的 RST 或注入包，以及 DPI 是否向服务器也注入。
3. 会话重组判断：对比 server 与 client 看到的 TCP 序列/重组差异，若 DPI 与服务器之间独立会话被完全重建，绕过难度很大。
4. 逐步验证：在受控环境尝试简单策略（头部微调）并观察触发率下降情况。

重要提示：如果评估显示属于上述无效类别，建议转向替代方案，如可信 VPS + 加密隧道，或改变服务端 IP/端口策略。

总结：在部署前必须验证 IP 可达性与 DPI 的重组能力；若 DPI 在中间重建或 IP 被封锁，zapret 的本地化策略通常无效，应考虑替代方案。

核心分析¶

目标：为某个被封锁站点找到既有效又最小副作用的策略组合。

可操作的测试流程（分步）¶

1. 建立基线：在不启用任何策略时使用 tcpdump/浏览器开发者工具记录正常请求/响应与触发表现（错误代码、重定向、RST）。
2. 低侵入尝试：启用轻量策略（如 Host 大小写变化、方法与路径微调、添加空格或尾部点），使用 dry-run 或仅对单个客户端生效，观察是否降低触发率。
3. 逐步升级：若无效，依次尝试：TCP 分段（改变 MSS/分段点）、延迟分段、伪包注入（RST/重定向）、IP_ID/片段操控与序号覆盖。每步只启用一项并记录影响。
4. 参数微调：对有效策略调整参数（分段大小、注入时机、序号偏移量）并 A/B 测试成功率与页面完整性。
5. 组合与回归测试：将有效单项组合，验证兼容性（TLS、长连接、视频流等）并在不同时间/负载下回测稳定性。
6. 部署与监控：仅对受影响 hostlist 生效，持续监控错误率、延迟、CPU、conntrack，保留回退脚本。

实用建议¶

• 记录与可复现性：详细记录每次变更与抓包，以便回滚和分享可复现步骤。
• 保守策略：优先保证页面可用性，再追求触发率的极限下降。

重要提示：在含 TLS 的场景中，避免破坏握手；任何会影响 TLS record 的策略需谨慎并先在受控环境验证。

总结：采用“基线—低侵入—增量升级—组合优化—监控回退”的系统化流程，可以为单个站点精细调优出既有效又稳定的策略集合。