nfq_handle_packet收不到包的主因是iptables规则未正确触发NFQUEUE：需确认规则使用-j NFQUEUE（非已废弃的-j QUEUE）、--queue-num与代码nfq_create_queue绑定的队列号严格一致，且链选择正确（如本机出包用OUTPUT而非POSTROUTING）。
nfq_handle_packet 为什么收不到包？检查 iptables 规则和 queue number 是否匹配
libnetfilter_queue 不是独立工作的，它依赖内核 netfilter 的 QUEUE 目标把包送到用户态。最常见问题是 nfq_handle_packet 长时间阻塞却没数据——大概率是 iptables 没真正把包送进来。
确认点有三个：
- iptables 必须用
-j NFQUEUE，不能写成-j QUEUE（后者是旧接口，已废弃） -
--queue-num值必须和代码中nfq_bind_socket绑定的队列号一致，比如 iptables 用--queue-num 0，代码里就得调用nfq_create_queue(h, 0, ...) - 确保规则加在正确链上：INPUT/OUTPUT 用于本机进出，FORWARD 用于转发；若想拦截本机发出的 SYN 包，
OUTPUT链比POSTROUTING更可靠（后者可能已被连接跟踪模块提前处理）
临时调试可加日志：运行 sudo iptables -I OUTPUT -p tcp --dport 80 -j NFQUEUE --queue-num 0 -m limit --limit 5/sec，避免 flood 导致程序卡死。
如何安全地修改 payload 并重新注入？别直接改 nfq_get_payload 返回的指针
nfq_get_payload 返回的是内核 skb 数据的只读映射，直接写会触发 segfault 或静默失败。真正修改需走「重建 packet」流程。
立即学习“C++免费学习笔记（深入）”；
典型做法是：
- 用
nfq_get_payload读出原始数据到用户缓冲区（如std::vector<uint8_t></uint8_t>） - 解析 IP/TCP 头（推荐用
libpcap的pcap_next_ex解析逻辑，或手撸偏移计算；注意 IP 总长、TCP 数据偏移、校验和字段都要重算） - 修改 payload 后，调用
nfq_set_verdict+nfq_set_payload注入新数据；注意nfq_set_payload第二个参数必须是完整 IP 包（含 IP 头），不能只传 TCP 段 - 务必重算 IP 校验和（
ip_summed = 0）和 TCP 校验和（需伪头+TCP段+data，Linux 内核不帮你算）
漏掉校验和重算，包大概率被接收端丢弃，现象是「看起来发出去了但对方收不到」。
深度过滤时怎么拿到五元组和连接状态？靠 nfq_get_nfmark 和 conntrack 接口协同
libnetfilter_queue 本身不提供连接跟踪信息。要判断 SYN/FIN/RST、是否属于已有连接、NAT 后的地址，得结合 libnetfilter_conntrack。
操作路径是：
- 先用
nfq_get_nfmark获取包的 nfmark 值（如果 iptables 里用了-j CONNMARK --save-mark） - 更可靠的方式：从
nfq_get_payload解析出源/目的 IP+端口，再用nfct_query(ct, NFCT_Q_GET, &tuple)查 conntrack 表；tuple需按方向填两次（正向+反向）才能准确定位连接 - 注意 conntrack 查询是阻塞 I/O，高并发下建议用异步方式（如 epoll +
nfct_open(0)创建非阻塞句柄），否则一个慢查询拖垮整个 queue 处理线程
单纯靠包内容判断「是否 HTTPS」容易误判（SNI 在 TLS ClientHello 里，但加密后看不到），此时必须依赖 conntrack 的 orig_l4proto == IPPROTO_TCP && orig_dst_port == 443 这类元数据。
多线程处理 queue 时 nfq_handle_packet 为啥崩溃？libnetfilter_queue 不是线程安全的
所有 struct nfq_handle* 和 struct nfq_q_handle* 对象都绑定到单个线程。多个线程共用同一个 h 调用 nfq_handle_packet 会破坏内部缓冲区，表现是随机 segfault 或 errno = EAGAIN 频发。
正确方案只有两个：
- 单线程循环调用
nfq_handle_packet，收到包后用线程池处理解析/过滤逻辑，最后仍由主线程调用nfq_set_verdict（因为 verdict 必须在原 socket 上回复） - 开多个 queue（iptables 用不同
--queue-num），每个 queue 绑定独立nfq_handle和独立线程；但要注意 CPU 亲和性——同一连接的包可能被 hash 到不同 queue，导致状态不一致
没有「线程安全的 queue handler」这种东西，文档里明确写了「not thread-safe」，别试图加 mutex 绕过。
