SO_REUSEPORT是Linux 3.9+引入的内核级端口复用机制，允许多进程/线程独立绑定同一IP+端口，由内核基于四元组哈希分发连接，实现无锁负载均衡；其生效需所有进程显式启用、euid一致且内核支持。
排查 Linux 中 SO_REUSEPORT 端口复用问题，关键不是“端口是否被占”，而是确认“多个进程是否真的在用同一 IP+端口 并启用了 SO_REUSEPORT”，以及内核是否按预期分发连接。直接用 netstat 或 ss 看到多个 LISTEN 状态的同端口条目，只是表象；真正要验证的是复用是否生效、是否安全、有没有冲突。
确认进程是否真正启用 SO_REUSEPORT
SO_REUSEPORT 不是默认开启的，必须显式设置套接字选项。仅靠 lsof -i :8080 或 ss -tlnp | grep :8080 显示多个监听进程，不能说明它们用了 SO_REUSEPORT —— 它们可能只是绑定了不同 IP（如 127.0.0.1 和 192.168.1.10），或其中部分进程因未设选项而实际无法共存（会触发 bind 失败，但错误可能被静默吞掉）。
- 检查进程启动日志或代码：Go 应用需确认用了
ListenConfig.Control并调用unix.SetsockoptInt(fd, unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)；C 程序需在bind()前调用setsockopt(..., SO_REUSEPORT, ...) - 用
cat /proc/配合/fd/ / readlink查 socket fd 类型，再结合bpftrace或strace -e trace=setsockopt,bind -p捕获系统调用，确认SO_REUSEPORT是否被设置 - 若某进程启动时报 “Address already in use”，但其他进程已监听同端口，大概率是它没开 SO_REUSEPORT（或开了但用户 ID 不一致）
验证内核是否允许多实例绑定
SO_REUSEPORT 有严格的安全前提：所有绑定同一地址+端口的 socket，其 effective user ID 必须完全相同。一个 root 进程和一个普通用户进程无法共用 8080 —— 即使都设了 SO_REUSEPORT，后启动的会 bind 失败。
- 用
ps -eo pid,euid,comm | grep your_server检查所有目标进程的 euid 是否一致 - 确认内核版本 ≥ 3.9：
uname -r；低于此版本 SO_REUSEPORT 不可用，即使代码设置了也会被忽略 - 检查是否禁用了该特性（极少见）：
sysctl net.ipv4.ip_unprivileged_port_start不影响 SO_REUSEPORT，但可排除低权限端口限制干扰
观察连接分发是否均衡
SO_REUSEPORT 的核心价值是内核级负载均衡。如果多个进程监听同端口，但连接几乎全落到某一个上，说明复用未生效或哈希倾斜严重。
- 用
ss -tnp state established '( sport = :8080 )' | awk '{print $7}' | sort | uniq -c | sort -nr统计每个进程持有的 ESTABLISHED 连接数 - 发起一批来自不同客户端 IP 的请求（避免哈希碰撞），观察各进程 accept 日志或连接计数增长是否大致均匀
- 注意：哈希基于四元组（源IP、源端口、目的IP、目的端口），同一客户端反复请求可能总落到同一进程 —— 这是正常行为，不是故障
区分 SO_REUSEADDR 和 SO_REUSEPORT 的误判
很多“端口复用”排查失败，源于把 SO_REUSEADDR 当成 SO_REUSEPORT。前者解决重启卡顿，后者才支持多进程并行监听。
- SO_REUSEADDR 允许新 socket 绑定 TIME_WAIT 中的端口，或绑定不同 IP 的同端口，但它 不允许多个进程同时 listen 0.0.0.0:8080
- 若看到多个进程监听
127.0.0.1:8080和0.0.0.0:8080，这是 SO_REUSEADDR 的合法行为，不是 SO_REUSEPORT - UDP 场景下，SO_REUSEADDR 允许多个 UDP socket 绑定同端口（但只最后一个能收单播包），而 SO_REUSEPORT 才让所有 socket 都能公平收包
