十分诡异的问题，web服务器（有防火墙保护），用telnet模拟http请求可以正常访问，用浏览器总是tiemout
我的web服务器是通过iptables防火墙保护的。web服务器和firewall在同一台物理机器上，firewall是dom0，web服务器在其中一个虚拟机上。OS是SUSE Linux Enterprise Server 11 SP1 - 2.6.32.12-0.7，web server是apache。
iptables配置如下：
iptables -t nat -A PREROUTING -s 0/0 -d $PUBLIC_ADDR -p tcp --dport $WEB_PORT -j DNAT --to-destination $INTERNAL_ADDR:80
其中PUBLIC_ADDR为服务器的对外地址，WEB_PORT为对外的web的端口（80），INTERNAL_ADDR为web服务器地址
我的问题是：
在外网访问web服务器，可以通过telnet 80端口模拟http请求并能得到正确的结果，可是通过任意浏览器（IE，firefox，chrome，Safari)或者curl，wget访问，总是connection可以建立，但是recv timeout。
在外网通过浏览器访问的话
在dom0上通过tcpdump查看连接过程，tcp/ip连接建立起来后，竟然又收到一个 ttl为127的RST的TCP包，导致连接被断开。
同时在client端通过tcpdump查看，则是建立连接后发送http request，然后没有收到服务器的返回（这说明dom0上收到的那个RST包肯定不是client端发的）。
在外网f通过telnet模拟访问的话
在dom0和client端通过tcpdump查看一切都正常。
web服务器肯定没有问题，因为
1. 在dom0上访问web服务器是没有问题的
2. 如果把WEB_PORT改成8080或者其他值，只要不是80，在外网用浏览器都可以正常访问web 服务器。
一些更详细的信息，用browser访问时：
1. 在client端用tcpdump看，看到5个包：
Client -> Server: TCP SYN
Server -> Client: TCP ACK SYN
Client -> Server: TCP ACK
Client -> Server: HTTP 请求 ===》这个包服务器收不到
Server -> Client: TCP Ack (urgent pointer 是 ffff，不是0）===》这个包不知道是谁发的？服务器的tcpdump看不到这个包，另外，为什么会urgent pointer会不是0？
2. 在server端用tcpdump看，却看到了四个包
Client -> Server: TCP SYN
Server -> Client: TCP ACK SYN
Client -> Server: TCP ACK
Client -> Server: TCP RST ===》 这个包不知道是谁发出来的？在客户端看不到有发送
求高手指点，十分感谢！
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
这个是你的idc给屏蔽了。telnet可以通，用浏览器不通，我遇到过。
字太多了
回复
@甘薯 ，
还有个好办法，试试吧80端口的协议改成其他的，比如mysql，ssh，smb，等等，看能否使用。验证是否是ISP劫持http 80 端口。
谢谢大米和甘薯，我试试 我说的telnet，不仅仅是连接，而是模拟http GET，都可以的，可以正确获取
点击此处输入评论
楼主的问题貌似我碰到过，我说一下我的问题描述：
在阿里云上买了个云服务器，jdk+tomcat+nginx:80端口都配置好了，域名解析指向正确的IP。
第一天通过域名访问80端口，可以正常访问的；
第二天通过域名访问80端口就跳到了阿里云备案提示页面；
我把nginx端口改成8080就不会跳到阿里云备案提示页面了；
------------------------------------------ 咯咯机 ---------------------------
我感觉楼主问题和我遇到的差不多，就是ISP拦截了。
原理很简单telnet模拟的只是建立连接，在浏览器中访问包括建立连接和发送http协议请求2个部分。ISP允许你简历链接，但是劫持了你的http请求。
80端口被强，防火墙那设置估计有点问题，估计是
引用来自“loyal”的评论
真逗,不看
iptables的设置,尽看些没用的.
引用来自“泡不烂的凉粉”的评论
改成其他没问题， 这就足以证明问题不在你这边， 如果想确认问题， 直接找个机器对机器的链接，中间不经过路由等设备做访问测试。
我认为最大的问题可能是中间设备，比如isp的过滤。
引用来自“loyal”的评论
真逗,不看
iptables的设置,尽看些没用的.
真逗,不看
iptables的设置,尽看些没用的.
改成其他没问题， 这就足以证明问题不在你这边， 如果想确认问题， 直接找个机器对机器的链接，中间不经过路由等设备做访问测试。
我认为最大的问题可能是中间设备，比如isp的过滤。