搜索了一大圈没找到到答案，最终通过重启 ss 所在的服务器解决。过程如下
在服务器查看 ss 服务的端口的使用情况，发现大量 tcp 半连接状态（SYN_RECV），因为刚刚尝试连接网络失败百度得出两种可能：
1、一种是客户端没有收到服务器发送的 [SYN,ACK] 包
尝试 ping 客户端 ip，成功，排除这种可能
2、另一种可能是对方收到了 [SYN,ACK] 包却没有 ACK，
这种情况又分为两种可能 1. 一种是对方根本就不打算 ACK，一般在对方程序有意为之才会出现，如 SYN Flood 类型的 DOS/DDOS 攻击；(排除)2. 一种可能是对方收到的 [SYN,ACK] 包不合法，常见的是 SYN 包的目的地址（服务地址）和应答 [SYN,ACK] 包的源地址不同。这种情况在只配置了 DNAT 而不进行 SNAT 的服务网络环境下容易出现，主要是由于 inbound（SYN 包）和 outbound（[SYN,ACK]包）的包穿越了不同的网关 / 防火墙 / 负载均衡器，从而导致 [SYN,ACK] 路由到互联网的源地址（一般是防火墙的出口地址）与 SYN 包的目的地址（服务的虚拟 IP)不同，这时客户机无法将 SYN 包和 [SYN,ACK] 包关联在一起，从而会认为已发出的 SYN 包还没有被应答，于是继续等待应答包。这样服务器端的连接一直保持在 SYN_RCVD 状态（半开连接）直到超时。………………超出现有知识能解决的范围，干脆重启 ss 服务所在服务器实例启动 ss 服务，发现 ip 更换，重新配置 ss 客户端连接 googlebingo！连接成功