UDP 可以按 UID 分流吗？

[yueyinqiu]

目前在尝试做一个用户可自己配置的 TUN。思路是系统级别起一个 mihomo 做 TUN，然后上游按照 UID，分流到不同用户的 mihomo 中（当然用户的 mihomo 要从物理网卡/回到系统级 mihomo 从 DIRECT 出站）。

现在 TCP 的流量好像已经成功了，但是 UDP 会出现 could not get uid。想问下大佬们有什么办法吗？

（稍后会尝试补一个可复现的仓库）

[yueyinqiu]

另外，之前尝试过 #3324，但好像不能解决这个

[yueyinqiu]

有时候 TCP 好像也会漏？ 😿

[QuantIntellect]

TL;DR：能，但别靠 UID 规则逐连接反查，更稳的是在 TUN 上用 include-uid，让内核按 UID 分流（见下面「按用户分流」）。UDP 报 could not get uid，先排除「代理不支持 UDP」，再看「双栈 socket」（每个用户自己的 mihomo 转发 UDP 用的就是这种 socket）。

看了下源码（Alpha 69c16319）。我这边没法在你的环境里验证，下面按排查顺序说。

1. 先排除：代理不支持 UDP

系统级 mihomo 里指向用户 mihomo 的那个 proxy 必须支持 UDP：socks5 要写 udp: true（默认是 false），http 类型本身不支持 UDP。否则 UID 规则就算匹配上了也会被跳过（tunnel.go#L684-L687，只打一条 debug 级别的 xxx UDP is not supported），UDP 落到后面的规则；在没打 #3324 的版本里，后面的 UID 规则就会打 could not get uid。（用户 mihomo 那边的 socks/mixed 入站默认就支持 UDP，别关掉就行。）

2. 双栈 socket（推测）

桌面 Linux 的 resolveSocketByNetlink 只发一次 INET_DIAG dump，family 跟着包的源地址走，IPv4 包就用 AF_INET（L99-L103）。内核 dump 时会跳过 sk_family 不同的 socket（udp_diag.c#L120-L121，TCP 同理：tcp_diag.c#L509-L510）。所以 AF_INET6 双栈 socket（IPV6_V6ONLY=0）发出的 IPv4 包什么都查不到，结果就是 process not found。Go 里用通配地址 net.ListenPacket("udp", ":0") 开的 socket（quic-go 客户端就是这样）、默认配置的 Java（java.net.preferIPv4Stack=false）都是这种。

你这个架构里最直接的例子就是每个用户自己的 mihomo。Linux 上 DIRECT、socks5、ss 的 UDP 出站都是 ListenPacket(ctx, "udp", "", …)（direct.go#L45、dialer.go#L79-L87，Linux 的 ParseNetwork 不改 network），开出来就是双栈 AF_INET6；TCP 则是直接 Dial IPv4 地址，用的是 AF_INET。所以如果用户的 mihomo 走「回到系统级 mihomo 从 DIRECT 出站」（没设 interface-name，流量会再进一次 TUN），它转发出去的 IPv4 UDP 一律 process not found，TCP 却能查到，和你看到的现象一致。系统级 mihomo 不管用 UID 还是 PROCESS-NAME 去认它都一样，走的是同一个查找。也就是说，你看到的 could not get uid 有可能来自用户 mihomo 转发的这一跳，而不是用户的程序本身。

验证：临时设 find-process-mode: always 和 log-level: debug，用普通用户（非 root）分别跑：

# A：AF_INET
python3 -c 'import socket,time; s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM); s.sendto(b"x",("1.1.1.1",9999)); print(s.getsockname()); time.sleep(5)'
# B：AF_INET6 双栈，发往同一个 IPv4
python3 -c 'import socket,time; s=socket.socket(socket.AF_INET6,socket.SOCK_DGRAM); s.sendto(b"x",("::ffff:1.1.1.1",9999)); print(s.getsockname()); time.sleep(5)'

• A 的连接日志里，源地址后面应该有 uid=…。再看同一行末尾：match Uid(1000) using …（换成你的 UID）说明规则生效；如果有 uid= 却不是 match Uid(…)（比如 match Match using … 或 doesn't match any rule），说明 UID 规则没生效，去 debug 里搜 UDP is not supported（对应第 1 条）。
• 如果 B 没有 uid=，并且 debug 里是 [Process] find process error for 1.1.1.1: process not found，那就是双栈（第 2 条）。
• 如果用户的 mihomo 是回到系统级 mihomo 出站的，A 被转给用户 mihomo 之后，还会再出现一行同样发往 1.1.1.1:9999、源端口不同、没有 uid= 的 [UDP]：那是用户 mihomo 转发的那一跳，也是双栈。

别用 53 端口，会被 dns-hijack 截走。用 root 跑 ss -uanp，本地地址显示为 *:端口 或 [::ffff:…]:端口 的就是这种 socket，可以看出是哪些程序（用户 mihomo 的 UDP socket 也会显示成 *:端口）。

另外几点

• netlink 拿到 UID 后还要扫 /proc/*/fd。扫到一半有进程退出会直接返回错误（L191-L193），tunnel.go#L356-L367 一见到错误就连 UID 一起丢掉，debug 里会是 process of uid(…),inode(…) not found 或 lstat /proc/…。fix: retain known socket UID when process lookup fails #3324 修的就是这一条，但它只在 netlink 已经找到 socket 时才有用；process not found 时 UID 本来就是 0，所以对双栈 UDP 没效果。TCP 偶尔漏可能是这条，也可能是 Java 这类双栈 TCP，看 debug 里的错误就能分开。
• 你试 fix: retain known socket UID when process lookup fails #3324 时的现象也能用来区分：fix: retain known socket UID when process lookup fails #3324 之后，UID 规则只在 UID 为 0 时才打 could not get uid。如果这条 warn 还在，说明 UID 确实是 0（查找失败，看第 2 条；或者那条流量本来就是 root 的）；如果 warn 没了但 UDP 还是没走到用户的 mihomo，就看第 1 条。（没打 fix: retain known socket UID when process lookup fails #3324 的版本里，uid.go#L48-L53 是规则没匹配就打这条 warn，哪怕已经拿到了别的用户的 UID。）
• UID 0 永远匹配不上（metadata.Uid != 0），所以别用 root 测。

按用户分流：逐连接反查总有竞态（比如发完就关的 UDP socket）。更稳的是让内核在路由时就按 socket 的 UID 分：TUN 的 include-uid / include-uid-range / exclude-uid(-range)（仅 Linux，需要 auto-route）会被 sing-tun 变成 ip rule … uidrange（tun_linux.go#L647-L663）。比如在系统级 mihomo 里给每个用户一个 tun listener，用 proxy: 直接交给他的 mihomo。带 proxy: 的入站在 tunnel.go#L318-L325 就返回了，根本不查进程，也不走规则，所以没有第 1 条的 UDP 检查；但 proxy: 指向的得是 socks5，http 照样转不了 UDP：

listeners:
  - name: tun-1000
    type: tun
    device: tun1000              # 每个用户的 device / 地址 / table-index 都要不同
    auto-route: true
    inet4-address: [198.19.0.1/30]
    iproute2-table-index: 2100
    # 每个实例占用 rule index ~ index+10，互相不能重叠（间隔 ≥ 11）；保留顶层 tun 时 index+10 要小于它的 9000
    iproute2-rule-index: 8000
    include-uid: [1000]          # 范围写 include-uid-range: ["1000:1999"]，必须用冒号
    proxy: user-1000             # proxies 里 type: socks5 的条目，指向该用户 mihomo 的 socks/mixed 端口

有 IPv6 的话，每个 TUN 也要配不同的 inet6-address，否则该用户的 v6 流量不会进这个 TUN。

DNS 要注意：listener 型 tun 默认 dns-hijack: [0.0.0.0:53]（parse.go#L68），所有发往 53 端口的查询都由系统级 mihomo 自己的 DNS 直接回答（dns.go#L21-L28），不会经过 proxy: 交给用户的 mihomo。想让查询原样走 proxy:，可以在这个 listener 上写 dns-hijack: []；但发往 inet4-address 下一个地址（例子里是 198.19.0.2）:53 的查询始终会被劫持（server.go#L299-L303）。开了 auto-route 时，默认的 dns-mode 还会用 resolvectl 把这个地址登记成该 TUN 的 DNS（systemd-resolved 会把它当成全局 DNS 之一），用户多的话可以加 dns-mode: disabled 关掉。另外，走 systemd-resolved 的查询是 resolved 自己发的，本来就不按用户分。DNS 这段是看源码得出的，没实测。

用户自己的 mihomo 出站必须绕开所有 TUN（用该用户的 UID 跑的话，出站会被 include-uid 拉回自己的 TUN，形成环路）。一种是在用户 mihomo 里设 interface-name: <物理网卡>（5.7+ 内核非 root 也能绑）；另一种是用专门的 UID 跑，并把这些 UID 写进顶层 tun 的 exclude-uid（或者干脆不要顶层 tun）。否则它会掉进顶层 TUN，在那里又只能逐连接查 UID/进程来识别，UDP 照样认不出来。

多 TUN 这套我没实测过。不用 listener 的话，手写 ip rule add uidrange … 或 nftables meta skuid 也是同一个思路。

上游修复 patch（能编译，还没在 Linux 上跑过）

思路：AF_INET 查不到时，再用 AF_INET6 + v4-mapped 源地址查一次。Android 的 procfs 兜底本来就是 udp、udp6 都查（L310）。这个 diff 能直接 git apply 到 69c16319，linux/amd64、linux/arm64、android/arm64 下都能编译，go vet 也能过，但还没在 Linux 上实际跑过：

--- a/component/process/process_linux.go
+++ b/component/process/process_linux.go
@@ -5,6 +5,7 @@ import (
 	"bytes"
 	"encoding/binary"
 	"encoding/hex"
+	"errors"
 	"fmt"
 	"net/netip"
 	"os"
@@ -90,7 +91,16 @@ func findProcessName(network string, ip netip.Addr, srcPort int) (uint32, string
 	return uid, pp, err
 }
 
-func resolveSocketByNetlink(network string, ip netip.Addr, srcPort int) (uid uint32, inode uint32, err error) {
+func resolveSocketByNetlink(network string, ip netip.Addr, srcPort int) (uint32, uint32, error) {
+	uid, inode, err := resolveSocketByNetlinkFamily(network, ip, srcPort)
+	if errors.Is(err, ErrNotFound) && ip.Is4() {
+		// 双栈 AF_INET6 socket 也会发 IPv4 包，但 INET_DIAG 只 dump 同 family 的 socket
+		return resolveSocketByNetlinkFamily(network, netip.AddrFrom16(ip.As16()), srcPort)
+	}
+	return uid, inode, err
+}
+
+func resolveSocketByNetlinkFamily(network string, ip netip.Addr, srcPort int) (uid uint32, inode uint32, err error) {
 	request := &inetDiagRequest{
 		States: 0xffffffff,
 		Cookie: [2]uint32{0xffffffff, 0xffffffff},

如果你跑完 B 确实拿不到 UID，我可以把这个整理成 issue 或 PR。

[yueyinqiu]

感谢大佬！

双栈的问题已经在 NixOS 虚拟机复现，且 patch 是有效的：https://github.com/yueyinqiu/Mihomo3391/tree/main/repro （最近事情比较多，主要让 AI 复现的，但人工验过了 1 -> 2 -> 3 的 diff 是正确的，即 2 是把测试脚本改成双栈、3 是加上 patch。）

另外每用户一个 TUN 的方案也让它试了一下，发现这样一个现象不知道是预期内的还是确实有问题：

系统级 mihomo 起一个 listeners 里的 type: tun（include-uid: [1001]），再用 proxy: 把这个 uid 的流量直接交给用户自己的 mihomo（用户 mihomo 的 socks 监听在 127.0.0.1:1080），不走 rules、不查进程。

实测发现 stack: system 下 proxy: 不生效：

• 在 tun 设备上抓包，能看到 alice 的 TCP SYN 正常进入了 tun；
• 但在 loopback 接口（lo）上抓「系统 mihomo → 127.0.0.1:1080」的流量，一条都没有——也就是说系统 mihomo 收下了这个 SYN，却没有按 proxy: 去连用户 mihomo 的 socks 端口；
• 结果就是 alice 侧一直超时，什么也转发不出去。

把 stack 从 system 改成 gvisor 后就一切正常了：TCP/UDP 都能按 include-uid 分流，并通过 proxy: 转给用户 mihomo。

[yueyinqiu]

在做 per-user-tun 的时候发现，系统级 mihomo 在发到用户 socks5 proxy 的时候好像有一段这个：

func (b *Base) ResolveUDP(...) error {
  if !metadata.Resolved() {
     ip, err := resolveIPWithResolver(ctx, metadata.Host, ...)
     metadata.DstIP = ip
  }
  return nil
}

它自己把 udp 的目标 ip 解析出来了而不发送域名……？这是刻意的设计吗（tcp 是发域名的）

---

Update: 好像已经有 PR 了 #3352