使用iptables设置Socket MARK与TTL后，getsockopt无法读取正确值的原因

我来帮你拆解下这个问题的核心——你混淆了iptables层面的标记/TTL修改，和socket选项里的MARK/TTL的本质区别，这才导致结果不符合预期：

一、为什么拿到的MARK是0？SO_MARK 和 CONNMARK不是一回事 #

你通过iptables设置的是连接跟踪标记（CONNMARK），但getsockopt调用的SO_MARK获取的是socket自身的专属标记，两者完全独立：

• 你的iptables规则是给新进入的数据包打MARK，再通过CONNMARK --save-mark把这个标记绑定到连接跟踪条目上，后续数据包用--restore-mark复用这个标记。这些操作全在netfilter的连接跟踪层面，和socket本身的属性没有任何关联。
• SO_MARK是socket的固有属性，只有当你主动用setsockopt给socket设置过这个值，或者进程继承了带MARK的socket时，getsockopt才能拿到非0的结果。

解决思路 #

如果想在应用层获取连接的CONNMARK，有几种可行方案：

• 解析/proc文件：读取/proc/net/nf_conntrack，根据连接的源/目的IP+端口匹配对应的条目，从中提取MARK字段（注意这个文件内容量大，解析需要做字符串匹配）。
• Netlink交互：通过netlink套接字和内核的nfnetlink接口通信，直接查询指定连接的CONNMARK，这种方式效率更高，适合编程场景。
• 替换iptables设置：如果业务场景允许，直接在应用层用setsockopt(connfd, SOL_SOCKET, SO_MARK, &mark, sizeof(mark))给socket设置MARK=100，替代iptables的MARK规则，这样getsockopt就能直接拿到你设置的值。

二、为什么拿到的TTL是64？IP_TTL是发送默认值，不是接收数据包的TTL #

getsockopt(IPPROTO_IP, IP_TTL)获取的是当前socket发送数据包时的默认TTL值（Linux系统默认就是64），而你用iptables设置的TTL --ttl-set 33是在PREROUTING阶段修改已经到达服务器的数据包的TTL字段——这个修改只针对当前接收的数据包，不会改变socket本身的默认发送TTL配置。

解决思路 #

如果想获取到达服务器的数据包的实际TTL值，你需要：

• Raw套接字捕获：使用raw套接字（需要root权限）捕获进入的IP数据包，直接解析IP头里的TTL字段。
• Recvmsg获取元数据：对于TCP/UDP连接，可以用recvmsg结合IP_PKTINFO选项（Linux系统支持），获取接收数据包的IP头元数据，其中包含实际的TTL值。

内容的提问来源于stack exchange，提问作者scottcai