server 端的 cannot assign requested address
source link: https://zhangguanzhang.github.io/2022/03/16/cannot-assign-requested-address/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
server 端的 cannot assign requested address
今天碰到了这个问题，但是最终结果出乎意料
项目相关部分
客户的 OA 对接我们的应用，使用过程中会调用我们的接口，我们的接口再回调客户的回调地址。调用流是：
客户 OA 后端 ----> 我们应用 A 的后端 -----> 我们应用 B 后端 -----> 客户写的回调地址
然后我们接口 A 返回 B 访问回调的报错：
"Get http://10.192.xxx.xxx/xxxxinfo?...: dial tcp 10.192.xxx.xxx:80: connect: cannot assign requested address"
一开始看到这个报错的时候就知道，这个报错是 TCP 四元组哪个组不够用都会报错这个的，但是最优先和最常见的就是 client 的端口耗尽，也就是 client 端的 port range 不够用了，一般是这个 B 服务机器上 client 的端口达到上限了，可以通过下面参数调整下：
sysctl -a |& grep port | grep range
结果实际上上去 B 服务上 curl 这个 url 能返回 http 状态码。起初以为真的是我们服务 B 在瞬间有端口没释放的 bug，但是 curl 能返回 http 状态码（但是内容是空的），说明 tcp 层面没问题。因为 http 返回信息是空的，我们初步怀疑到是客户的回调服务偷偷更新了后导致的。后面让客户取消掉他们回调 url 的后端校验 token 逻辑。他们换了后还是一样，然后他们把这个接口的逻辑代码截图了，以及把回调服务的日志发过来的。
看了下日志，发现报错信息里有 token 校验过的和没有校验成功的，校验失败的那些原因都是过期了。询问了下发现回调的 IP 后面有好几个服务副本，让客户他们去检查机器时间试试，然后客户下班了，另一个同事说可以单独修改我们服务 B 的设置，指向单台副本绕过负载均衡试试，最后发现 5 个每个单独都正常，指向负载均衡的 IP 就不行，询问后发现是硬件负载均衡。最后第二天客户排查到是硬件负载均衡的连接数异常。是深信服的硬件负载均衡。
结论和学习
其实一开始的 curl 正常能返回 http 状态码就说明 tcp 没问题，不过这次也算是见识到了，server 端的端口不够也会返回 cannot assign requested address 的报错，也就是主动打开还是被动打开，这个错误的信息都是一样的。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK