“Cannot assign requested address”源于短连接风暴、TIME_WAIT堆积与端口池过小；需同步减少新建连接（优先启用keep-alive或requests.Session）、加快端口回收（开启tcp_tw_reuse）、扩大端口范围（1024–65535）。
核心问题是：短连接风暴 + TIME_WAIT堆积 + 端口池太小 → “Cannot assign requested address”。这不是代码写错了，而是系统资源被高频 curl 耗尽。解决要从减少新建连接数、加快端口回收、扩大可用端口池三方面同步入手。
优先启用连接复用（最有效）
curl 默认每次请求都建新 TCP 连接，这是最大根源。必须强制复用：
- 在脚本中统一加
-H "Connection: keep-alive"，并用--http1.1显式指定协议（HTTP/2 默认复用，但部分服务端不兼容） - 改用
curl --reuse（libcurl 7.62+ 支持），或更稳妥地：用curl -K配合配置文件批量复用同一 host 的连接 - 若调用量极大（如每秒百次以上），直接换长连接客户端：用 Python 的
requests.Session()、Go 的http.Client（带 Transport 复用连接池），避免 shell curl 的进程开销和连接隔离
调大临时端口范围并启用快速复用
默认 32768–60999（约 28k 端口）完全扛不住高并发 curl：
CurlShip Directory Submission
下载
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
- 临时扩到
1024 65535：执行echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range - 永久生效：在
/etc/sysctl.conf加一行net.ipv4.ip_local_port_range = 1024 65535，再运行sysctl -p - 必须开启
net.ipv4.tcp_tw_reuse = 1（要求net.ipv4.tcp_timestamps = 1，现代内核默认已开）——它允许内核在时间戳校验安全前提下，把 TIME_WAIT 端口立刻用于新连接（仅对客户端 connect 有效）
降低 TIME_WAIT 堆积压力
哪怕开了 reuse，大量短连接仍会短暂卡住端口。配合以下手段进一步缓解：
- 缩短 FIN 超时（非直接缩 TIME_WAIT，但能加速进入阶段）：
net.ipv4.tcp_fin_timeout = 30 - 确认未启用
tcp_tw_recycle（已废弃且 NAT 下必出问题，Linux 4.12+ 内核移除，设为 0 更安全） - 检查定时任务是否“堆叠触发”：比如 cron 每分钟跑一次，但上一轮没结束就启下一轮 → 用
flock或临时锁文件串行化，避免连接数指数级增长
验证与监控（别等报错才查）
优化后要持续盯住关键指标：
- 实时看 TIME_WAIT 数：
ss -ant state time-wait | wc -l，应明显低于端口上限（如扩到 64k 后，稳定在 5k 以内较健康） - 确认端口范围：
cat /proc/sys/net/ipv4/ip_local_port_range - 抓一个典型 curl 进程，看其 fd 和连接：
lsof -p $(pgrep -f "curl.*your-target") -iTCP，确认连接是否复用（源端口重复出现） - 若用 Docker/K8s，注意宿主机参数生效，容器内无需单独调 —— ephemeral 端口由宿主机内核分配
