结合你碰到的这个问题——macOS服务器上的局域网服务重启后正常，但几小时后所有设备都报连接重置，还有你提供的客户端和服务器侧抓包，咱们来一步步拆解：

问题核心现象 #

你的服务运行在192.168.50.42（macOS 14.1/多个13.0版本），客户端是192.168.50.228，网关是AsusWRT路由器（192.168.50.1）。故障触发时：

• TCP握手能正常完成，但客户端发送GET请求后，网关会冒充服务器回复ACK
• 客户端收到非预期的ACK后，直接发送RST重置连接
• 服务器侧根本看不到网关的IP，只收到网关冒充客户端发来的RST，说明网关在全程拦截并篡改流量

客户端侧抓包细节（故障状态） #

下面是客户端抓包的关键时序和完整数据：

1. 客户端发起SYN，服务器回复SYN+ACK（注意此时回复的源MAC是路由器，已经有异常）
2. 握手完成后客户端发GET请求，网关立刻代替服务器回复ACK
3. 客户端判定连接异常，发送RST；后续重传请求也被服务器的RST阻断

No.     Time        Source          Destination     Source MAC   Destination MAC   Protocol   Length   Info
9154    4.932032    192.168.50.228  192.168.50.42   Client       Server            TCP        78       54054 → 8080 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1633977301 TSecr=0 SACK_PERM
9155    4.937303    192.168.50.42   192.168.50.228  Router       Client            TCP        78       8080 → 54054 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 TSval=1803376346 TSecr=1633977301 SACK_PERM
9156    4.937396    192.168.50.228  192.168.50.42   Client       Server            TCP        66       54054 → 8080 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=1633977306 TSecr=1803376346
9157    4.937488    192.168.50.228  192.168.50.42   Client       Server            HTTP       543      GET / HTTP/1.1
9158    4.941333    192.168.50.1    192.168.50.228  Router       Client            TCP        66       8080 → 54054 [ACK] Seq=1 Ack=1 Win=2051 Len=0 TSval=1803376351 TSecr=1633977306
9159    4.941385    192.168.50.228  192.168.50.1    Client       Router            TCP        54       54054 → 8080 [RST] Seq=1 Win=0 Len=0
9160    5.047863    192.168.50.228  192.168.50.42   Client       Server            TCP        517      [TCP Retransmission] 54054 → 8080 [PSH, ACK] Seq=1 Ack=1 Win=131712 Len=477 TSval=1633977417 TSecr=1803376346
9161    5.053608    192.168.50.42   192.168.50.228  Router       Client            TCP        54       8080 → 54054 [RST] Seq=1 Win=0 Len=0

服务器侧抓包细节（故障状态） #

服务器侧的抓包暴露了网关的另一个异常操作——发送ICMP重定向包，这是路由策略异常的典型信号：

1. 服务器正常回复SYN+ACK后，网关立刻发ICMP重定向给服务器
2. 服务器收到客户端的GET请求并回复ACK，但网关冒充客户端发RST断开服务器侧连接
3. 后续客户端重传请求，服务器只能回复RST

No.     Time        Source          Destination     Source MAC   Destination MAC   Protocol   Length   Info
1935    9.542822    192.168.50.228  192.168.50.42   Client       Server            TCP        78       54054 → 8080 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1633977301 TSecr=0 SACK_PERM
1936    9.543382    192.168.50.42   192.168.50.228  Server       Router            TCP        78       8080 → 54054 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 TSval=1803376346 TSecr=1633977301 SACK_PERM
1937    9.543747    192.168.50.1    192.168.50.42   Router       Server            ICMP       106      Redirect             (Redirect for host)
1938    9.548315    192.168.50.228  192.168.50.42   Client       Server            TCP        66       54054 → 8080 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=1633977306 TSecr=1803376346
1939    9.548317    192.168.50.228  192.168.50.42   Client       Server            HTTP       543      GET / HTTP/1.1
1940    9.548480    192.168.50.42   192.168.50.228  Server       Router            TCP        66       8080 → 54054 [ACK] Seq=1 Ack=478 Win=131264 Len=0 TSval=1803376351 TSecr=1633977306
1941    9.551754    192.168.50.228  192.168.50.42   Router       Server            TCP        54       54054 → 8080 [RST] Seq=478 Win=0 Len=0
1942    9.658227    192.168.50.228  192.168.50.42   Client       Server            TCP        543      [TCP Spurious Retransmission] 54054 → 8080 [PSH, ACK] Seq=1 Ack=1 Win=131712 Len=477 TSval=1633977417 TSecr=1803376346
1943    9.658367    192.168.50.42   192.168.50.228  Server       Router            TCP        54       8080 → 54054 [RST] Seq=1 Win=0 Len=0
1944    9.658987    192.168.50.1    192.168.50.42   Router       Server            ICMP       82       Redirect             (Redirect for host)

优先排查方向 #

根据我的经验，这种网关主动篡改局域网流量的问题，大概率和AsusWRT的这些设置相关：

• 端口转发/虚拟服务器规则：检查是否有针对8080端口的转发规则，可能规则配置错误导致网关误拦截局域网内的流量
• AI Protection安全防护：华硕路由器的入侵检测功能可能误判局域网HTTP流量，建议临时关闭该功能测试是否恢复正常
• 网关ARP/路由缓存：几小时后才出现故障，可能是网关的ARP缓存老化或路由表异常，导致网关无法正确转发服务器的回复，转而触发重定向或冒充回复
• macOS服务器网络设置：检查服务器的默认网关是否正确，是否开启了防火墙规则阻止了回复包，导致网关认为服务器不可达而介入

备注：内容来源于stack exchange，提问作者user1967944