环境：
阿里云LB 内网地址类型，代理后面的k8s上的服务
公司和阿里云之间vpn打通
在windows上进行访问一切正常，在相同的办公局域网linux主机内访问不通，mac笔记本访问同样不通，telnet 端口是正常的，就很诡异
抓包，windows安装wireshark，curl该地址，然后对该端口进行抓包，这个时候需要知道MSS这个东西了
在内网linux上或者mac上进行curl 该地址，然后去k8s对应的服务pod内进行tcpdump抓包
curl "http://10.255.30.26:8080/xxxxxxx&src=linux" #&src=windows这个后缀自己加的用于筛选抓包的信息
tcpdump -i any -vv -w src-linux #输出结果到src-linx文件，用于导出到wireshark查看分析使用
结果：
从windows正常能访问的上面进行curl 然后在服务端抓包比较，方法和上面相同，把src=linux改成src=windows，这个就是为了筛选结果用，随意命名
对于网络自己不是很清楚，但是和mss的确有关系，相关介绍参看下面
https://blog.51cto.com/virtualadc/692407
https://blog.csdn.net/scythe666/article/details/51967606
最终解决办法，在路由上加了一条
firewall-cmd --permanent --direct --add-passthrough ipv4 -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
参考http://www.enerco.si/blog/centos-and-masquerading
原文内容：
The other day I had weird problems with masqueraded connections. Certain HTTP connections were simply going deaf after a random amount of time. The behaviour seemed random at first, but then I discovered that only specific webservers like www.nmap.org or www.speedtest.net are affected. The server, doing the masquerading was based on Centos 7. It was also using the new FirewallD system, so I thought the problem might be there. Normally, I wouldn't bother, but this one somehow didn't let me sleep. Following the leads, I discovered that certain TCP packets are not coming through. How come, if all the PING replies are there? I could confirm that the really big packets are being lost. This brought me to the TCP fragmentation. enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1492 See the MTU (maximum transmission unit) value? I guessed certain packets are not being properly fragmented, thus not passing the route. Doing some reading, I found this: When a user requests a web site, a client/server negotiation occurs between the PC and the web server that hosts the web site. During the negotiation, a maximum MTU size is negotiated. Since the PC negotiates and its default MTU size is 1500 bytes (Windows 3x, 9x, NT, ME, and so forth), the web server negotiates an MTU size of 1500 bytes. Therefore, regardless of the MTU size you configure on the router, the web server still sends packets up to 1500 bytes in size. Luckily the guys at Netfilter wrote an extension that solves the problem. In the words of the author. This patch by Marc Boucher <[email protected]> adds a new target that allows you to examine and alter the MSS value of TCP SYN packets, to control the maximum size for that connection. As explained by Marc himself, THIS IS A HACK, used to overcome criminally brain-dead ISPs or servers which block ICMP Fragmentation Needed packets. Typical usage would be : # iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu So, applying this to the new firewalld system solved the problem. firewall-cmd --permanent --direct --add-passthrough ipv4 -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu A little bit of explanation here.