两程序可同端口，`ss -lntup` 查清再复用

Address already in use

这条报错通常出现在服务启动、容器端口发布或 bind() 阶段。在 Linux 上，它一般对应 EADDRINUSE，但还不能仅凭报错判断是旧进程未退出，还是 TIME_WAIT、IPv4/IPv6 重叠或容器端口映射冲突。此时不要直接添加端口复用选项，先查完整监听状态：

sudo ss -lntup
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo lsof -nP -iUDP:8080

排查后按实际状态处理：若旧服务还在提供服务，应停止旧进程或改用新端口；若只是服务快速重启时受到 TIME_WAIT 影响，可在确认目标系统规则后使用 SO_REUSEADDR；若确实要让多个独立进程共同监听一个端点，则应在所有 socket 上统一设置 SO_REUSEPORT，并核对系统支持、有效 UID 和端口权限。

同一个数字端口可以同时用于 TCP 和 UDP，两者维护各自的端口空间；真正容易冲突的是相同协议、相同本地地址和相同端口的重复绑定。

先分清 TCP、UDP 和真正的本地端点

排查端口冲突时，不要只记录“8080 被占用”，而应记录完整端点：协议、本地 IP、本地端口，以及绑定的是具体地址还是通配地址。按这些组合检查，通常更容易定位问题。

在 ss -lntup 输出中，TCP 监听项通常带有 LISTEN 状态；UDP 没有 TCP 那套 LISTEN/accept 生命周期，通常显示为 UNCONN。因此不能用“有没有 LISTEN”这一条标准同时判断 TCP 和 UDP。-n 避免反查域名，-p 显示 PID 和进程名；查看进程信息时通常需要 root 权限。

最常见的误判，是把端口号当成完整地址。127.0.0.1:8080 与本机另一个具体 IP 上的 IP:8080 可以是不同端点，但 0.0.0.0:8080 是 IPv4 通配地址，会覆盖所有本机 IPv4 地址；它与某个具体 IP:8080 是否冲突，要结合绑定顺序和 socket 选项判断。IPv6 的 :: 也类似，而且 IPv6 通配 socket 是否同时接收 IPv4 流量，受 IPV6_V6ONLY 和系统配置影响。在目标系统检查：

sysctl net.ipv6.bindv6only

IPV6_V6ONLY 需要在 bind() 前设置。不要因为输出里同时出现 :::8080 和 0.0.0.0:8080，就断言它们必然冲突或必然互不相关；双栈默认值在不同系统上可能不同，应在目标机器验证。

第二个误判，是把 TIME_WAIT 当成仍在运行的监听进程。ss -lntup 主要显示监听和已绑定 socket，历史连接需要另查：

sudo ss -antp state time-wait

TIME_WAIT 是 TCP 连接状态，不是另一个服务占着监听端口。它会影响某些服务重启时的重新绑定，因此 SO_REUSEADDR 常用于快速重启；但不能据此给所有服务都打开地址复用，更不能把它当成隐藏重复配置的通用办法。

第三个误判，是只在宿主机或只在容器里查端口。容器有独立网络命名空间，宿主机上的 127.0.0.1:8080:80 表示“宿主机 8080 发布到容器 80”，宿主机端口和容器内应用端口并不是同一个绑定位置。两个容器可以各自监听相同容器端口，但发布到同一个宿主机地址和端口时仍可能冲突。宿主机侧可以先看：

docker ps --format table

再分别核对宿主机监听状态和容器内应用监听状态；宿主机 ss 不能代替容器内检查。

最后还有一种看起来像“两程序同端口”的情况：父进程先创建、绑定并监听 socket，然后 fork()。子进程继承的是同一个已绑定 socket 和文件描述符，多个进程是在共同 accept() 同一个监听 socket，并没有各自执行第二次 bind()。这与两个独立程序各自创建 socket、竞争同一端点不是一回事，也不需要用 SO_REUSEPORT 补救。

SO_REUSEADDR 与 SO_REUSEPORT 到底差在哪

这两个名字看起来相似，目标却不同。已有资料把地址复用、端口复用与多进程监听及负载分流联系在一起，演示中也常见“第二个 TCP 进程先绑定失败，启用端口复用后两个进程都能监听”的过程。 但具体行为必须落到目标系统的 socket 规则上，Linux 的精确语义可查 man 7 socket、man 2 bind。

在 Linux 上，SO_REUSEPORT 的典型前提包括：所有要共同绑定的 socket 都设置该选项，并在 bind() 前完成设置；这些 socket 通常还需要具有相同的有效 UID。系统还可能施加端口绑定权限限制。因此只给其中一个进程加选项，并不能保证其他进程随后绑定成功。

SO_REUSEADDR 的最小 Python 示例只需体现 API 和调用顺序：

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(("0.0.0.0", 8080))
sock.listen(128)

如果要启动多个独立 TCP 监听进程，则使用 SO_REUSEPORT：

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
sock.bind(("0.0.0.0", 8080))
sock.listen(128)

这两段代码只展示选项位置，不承诺在不同系统上产生完全相同的结果。Python 官方文档也注明 SO_REUSEPORT 并非所有平台都提供；应先确认目标运行时是否存在该常量，而不是直接用 SO_REUSEADDR 替代。其他语言通常也有对应的 setsockopt API，调用顺序相同。

跨系统时还要留意 socket 选项的语义差异。Linux 对精确重复 TCP 绑定同时受 SO_REUSEADDR、SO_REUSEPORT 等规则约束；部分 BSD/macOS 系统中的 SO_REUSEADDR 本身可能允许重复绑定，并带来端口抢占或流量被意外转走的问题。Windows 的 SO_REUSEADDR 语义也与 Unix 不同，还需要结合 SO_EXCLUSIVEADDRUSE 及其版本文档判断。跨系统部署时，应分别查 Linux、目标 BSD/macOS 和 Windows 的官方文档，不要把 Linux 配置直接复制过去。

按报错原因处理，并用 PID 验证分流

选择复用选项之前，可以按现场证据直接对照处理：

如果旧服务本来就不应该继续运行，开启端口复用只是把重复启动隐藏起来。它不能消除配置冲突，还可能让请求被多个实例接收，使问题更难定位。

确认使用 SO_REUSEPORT 后，还要验证“实际由谁接收”，不能只看两个进程都显示启动成功：

sudo ss -lntup

在应用中记录 PID，例如：

print(f"pid={os.getpid()}", flush=True)

对于 HTTP 服务，可以连续发起多次请求：

for i in $(seq 1 100); do
  curl -fsS http://127.0.0.1:8080/ >/dev/null
done

再对照应用日志中的 PID。非 HTTP 协议应使用真实客户端建立连接。这里要验证的是请求是否由不同进程处理，不要预设固定轮询或严格均分；Linux 可能按连接四元组等因素选择监听 socket。

UDP 可以用最小客户端发送数据报，再检查接收进程的 PID 日志：

python3 - <<'PY'
import socket

with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
    sock.sendto(b"probe", ("127.0.0.1", 8080))
PY

真实业务协议应发送协议要求的报文。UDP 的副本投递、广播和多播行为与系统及配置有关：Linux 的普通单播复用端口通常由内核选择接收 socket，但广播、多播或允许副本投递的场景仍可能出现重复处理，必须按目标系统文档核对。

TCP 还要区分新旧连接。已经被某个监听 socket 接收的连接通常继续由原 socket 服务，复用端口主要影响后续新建连接。启用复用后，启动成功只代表端点可以共享，不代表流量分布符合预期。

按以下顺序处理：

1. 记录完整端点：TCP 还是 UDP、绑定 IP、端口、通配地址以及所在网络命名空间。
2. 用 ss -lntup 和 lsof 区分监听进程、TIME_WAIT、重复配置与容器映射冲突。
3. 仅在确实需要共享端点时，让所有参与者统一使用 SO_REUSEPORT；快速重启则先确认状态，再按系统规则使用 SO_REUSEADDR。
4. 用 PID 日志验证 TCP 新连接和 UDP 数据报的实际接收者，再决定是否保留该配置。

处理端口冲突时，先确认“谁、以什么协议、绑定在哪个完整端点上”，再决定是否复用，避免表面上解决了 Address already in use，却把真正的部署冲突藏到流量之后。