Routing: Fix process for macOS IPv4-mapped sockets

[yiguodev]

Summary

• accept Darwin AF_INET6 socket entries marked with the IPv4 ini_vflag when matching an IPv4 source
• add a real IPv4-mapped dual-stack TCP socket test
• add a synthetic socket-info regression test

Root cause

Darwin reports IPv4 connections created by dual-stack sockets as AF_INET6
with the IPv4 bit set in ini_vflag. FindProcess unmapped the source address
to IPv4, but then required the socket family to be AF_INET, so these entries
were always rejected. The existing address comparison already supports the
IPv4 bytes stored in the final four bytes of the Darwin address structure.

The non-root case described in #6533 is caused by the minimal SOCKS client
closing immediately after receiving Xray's success response. Once the socket
has lost its owning file descriptor, process lookup cannot recover its owner.
With the connection kept open, non-root AF_INET lookup works normally.

Fixes #6533.

Validation

• CGO_ENABLED=0 go test ./common/net -count=1
• go test ./common/net ./app/router ./proxy/tun -count=1
• GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go test -c ./common/net
• runtime SOCKS reproduction with AF_INET and IPv4-mapped dual-stack clients
• git diff --check

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[yiguodev]

@copilot review

[RPRX]

@yiguodev 话说你在 macOS 上实测修复了对吧，以及他那个 issue 说的问题二，我感觉 macOS 可能是必须要 root 权限的？

[yiguodev]

Codex 测了，我没测。问题二不需要 root 权限。

[RPRX]

@yiguodev 那你测一下问题二是否存在吧，虽然非 TUN 的话非要依赖匹配进程有点闲得蛋疼了，可以开多个 Socks/HTTP 入站

[yiguodev]

Codex 的测试用例包含问题二，确实存在，也修了。

[RPRX]

啊这个 PR 不就改了一行吗，修哪了？还是说以前的 PR 修了

[RPRX]

The non-root case described in #6533 is caused by the minimal SOCKS client closing immediately after receiving Xray's success response. Once the socket has lost its owning file descriptor, process lookup cannot recover its owner. With the connection kept open, non-root AF_INET lookup works normally.

而且看起来这 AI 对问题二的描述也不太对，因为问题二能被他“一律”复现，且如果是上述原因的话那么是否 root 应该没差别

况且 Socks 客户端正常时都不应该有上述行为吧，太抽象了

[yiguodev]

你划掉的疑问其实是对的，我前面的表述不准确。

这个 PR 的生产代码只修问题一：IPv4 源地址匹配时允许 AF_INET6 + INI_IPV4。问题二没有代码修复。原复现脚本收到 SOCKS success 后立即 close；Xray 先返回 success，再进入 dispatch/process lookup，所以查找时 owning fd 可能已经消失，于是报 process not found。

保持连接时，非 root 对同用户 AF_INET socket 的查找本来正常（不代表可查看其他用户的 socket）。我刚在 macOS 上以普通用户（uid 501）重跑了原有的 TestFindProcessDarwinTCP 和新增的 TestFindProcessDarwinTCPIPv4Mapped，两项均通过；新增测试覆盖的是问题一。

我之前说“问题二也修了”是错的。准确说法是：修正复现方式后，issue 所述同用户场景的“问题二”无法复现。抱歉。

[yiguodev]

看来我和 AI 都幻觉了。

[Fangliding]

这么不负责吗全都是AI

[RPRX]

@yiguodev 算了问题二不急，先看下 #6580 吧

[yiguodev]

全 AI 有什么问题吗? 。捋了一下，他的脚本流程和当前的 Xray 处理流程冲突，有问题是必然的。脚本中 socks 收到 response 后立刻关闭，而 Xray 的流程是 response -> dispatch -> findProcess ，所有报错没什么问题。可以认为是他的脚本有问题。

[Fangliding]

结果就是这样出了问题没一个活人说得清 用AI辅助排查写点代码没问题我也不是原始人 从排查到代码到验收全甩给agent 有问题就甩锅AI错了 大多数纯AI的pr我都是看一眼就关的 你弄的大都是我不想管的地方就一直没说啥 刚好看到上面一串忍不住了而已

[RPRX]

AI 无法背锅坐牢的问题在此刻具象化了，不过像这些非 Win 系统的有人 PR 就不错了，要求不了太多

[yiguodev]

@Fangliding 首先，这个 PR 已经两周了，不要苛求别人会记得所有细节。其次，我并没有甩锅 AI，我也说了我幻觉了。提到 Xray-core 的代码每一行我都看了，虽然不一定完全理解就是了。 最后，大家都是为爱发电，觉得 PR 质量太低关闭就是了，没必要在这里阴阳怪气。每个人都有自己的开发方式，我花着自己的 token，模型质量拉满，我不觉得这种开发方式有什么问题。