当squid设置为TPROXY时，在某些站点返回ERR_CONNECT_FAIL。 鱿鱼运行的服务器能够通过lynx，wget，curl等打开这些网站。 即使我们在浏览器中手动设置代理或使用简单的REDIRECT或DST-NAT，这些站点也可以打开。
从这个页面http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
它导致pathMTU（PMTUD）失败，可能使一些远程站点无法访问 。 如果您的客户端计算机通过以太网或DSL PPPoATM连接，则caching与客户端之间的所有链路的MTU均为1500或更多，这通常不是问题。 如果您的客户通过DSL PPPoE连接，那么这可能是一个问题，因为PPPoE链路通常具有减less的MTU（1472很常见）。
但是我也有与以太网相同的问题
这里是一个客户端的tcpdump：
点击这里查看tcpdump当我使用tproxy和问题出现
和
点击这里查看tcpdump当我手动设置代理在我的浏览器和everyhting正常工作
GET / HTTP/1.0 Host: 80.75.1.4 Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01 Accept-Encoding: gzip, compress, bzip2 Accept-Language: en User-Agent: Lynx/2.8.8dev.2 libwww-FM/2.14 SSL-MM/1.4.1 HTTP/1.0 504 Gateway Time-out Server: squid Mime-Version: 1.0 Date: Wed, 27 Feb 2013 15:39:03 GMT Content-Type: text/html Content-Length: 376353 X-Squid-Error: ERR_CONNECT_FAIL 110 X-Cache: MISS from cache.mysquid.com X-Cache-Lookup: MISS from cache.mysquid.com:3128 Connection: close ping -s 1500 80.75.1.4
PING 80.75.1.4 (80.75.1.4) 1500(1528) bytes of data. 1508 bytes from 80.75.1.4: icmp_req=1 ttl=58 time=5.28 ms 1508 bytes from 80.75.1.4: icmp_req=2 ttl=58 time=3.96 ms 1508 bytes from 80.75.1.4: icmp_req=3 ttl=58 time=4.28 ms
ping -s 1473 80.75.1.4 -M do
PING 80.75.1.4 (80.75.1.4) 1473(1501) bytes of data. From 109.110.160.171 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 109.110.160.171 icmp_seq=1 Frag needed and DF set (mtu = 1500) --- 80.75.1.4 ping statistics --- 0 packets transmitted, 0 received, +2 errors
ping -s 1472 80.75.1.4 -M do
PING 80.75.1.4 (80.75.1.4) 1472(1500) bytes of data. 1480 bytes from 80.75.1.4: icmp_req=1 ttl=58 time=4.33 ms 1480 bytes from 80.75.1.4: icmp_req=2 ttl=58 time=4.32 ms --- 80.75.1.4 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 4.320/4.329/4.338/0.009 ms
traceroute –mtu 80.75.1.4
traceroute to 80.75.1.4 (80.75.1.4), 30 hops max, 65000 byte packets 1 xxx10 (xxx10) 0.820 ms F=1500 0.681 ms 0.243 ms 2 yyy1 (yyy1) 2.969 ms 3.185 ms 2.994 ms 3 217.218.181.193 (217.218.181.193) 2.836 ms 2.381 ms 2.487 ms 4 217.218.185.22 (217.218.185.22) 3.617 ms 2.957 ms 3.176 ms 5 78.38.119.237 (78.38.119.237) 2.050 ms 1.808 ms 2.264 ms 6 217.11.30.250 (217.11.30.250) 3.522 ms 3.962 ms 2.674 ms 7 * 80.75.1.4 (80.75.1.4) 3.507 ms *
tracepath 80.75.1.4
1: cache.mysquid.com 0.092ms pmtu 1500 1: xxx10 0.380ms 1: xxx10 0.309ms 2: yyy1 3.390ms asymm 7 3: 217.218.181.193 2.671ms asymm 5 4: 217.218.185.22 2.944ms asymm 5 5: 78.38.119.237 1.684ms 6: 217.11.30.250 4.020ms 7: 80.75.1.4 3.915ms reached Resume: pmtu 1500 hops 7 back 58
还尝试了这些步骤http://wiki.squid-cache.org/SquidFaq/SystemWeirdnesses#Can.27t_connect_to_some_sites_through_Squid
我不知道相关与否，但我也有以下configuration
echo 1025 65000 > /proc/sys/net/ipv4/ip_local_port_range echo 0 > /proc/sys/net/ipv4/tcp_syncookies echo 131072 > /proc/sys/net/ipv4/tcp_max_syn_backlog echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter echo 1 > /proc/sys/net/ipv4/ip_forward echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/p2p1/rp_filter echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
并启用/禁用以下
#echo 0 > /proc/sys/net/ipv4/tcp_window_scaling #echo 0 > /proc/sys/net/ipv4/tcp_ecn
这是TPROXY的路线规则
/sbin/iptables -t mangle -N DIVERT /sbin/iptables -t mangle -A DIVERT -j MARK --set-mark 1 /sbin/iptables -t mangle -A DIVERT -j ACCEPT /sbin/iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT /sbin/iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129 ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
注意：与互联网提供商的连接在MTU 1476的GRE Tunnel上。
从你提供的tcpdump输出中，下面的行表示一个问题，也就是你的主机发送一个SYN到目的地，然后发送一个RST到目的地，但是当然TTL是不一样的，所以看起来像是一些TPROXY魔法：
12:55:17.255717 IP (tos 0x0, ttl 64, id 11025, offset 0, flags [none], proto TCP (6), length 56) xxx150.62568 > 80.75.1.4.80: Flags [S], cksum 0x5f7e (incorrect -> 0x3c92), seq 572035649, win 14600, options [mss 1460,sackOK,TS val 66378265 ecr 0], length 0 12:55:17.258877 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40) xxx150.62568 > 80.75.1.4.80: Flags [R], cksum 0xa779 (correct), seq 572035650, win 0, length 0 12:55:18.253670 IP (tos 0x0, ttl 64, id 11026, offset 0, flags [none], proto TCP (6), length 56) xxx150.62568 > 80.75.1.4.80: Flags [S], cksum 0x5f7e (incorrect -> 0x3b98), seq 572035649, win 14600, options [mss 1460,sackOK,TS val 66378515 ecr 0], length 0 12:55:18.257916 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40) xxx150.62568 > 80.75.1.4.80: Flags [R], cksum 0xa779 (correct), seq 572035650, win 0, length 0
这似乎不是一个MTU问题。 要开始排除故障，我build议删除TPROXY （假设你正在使用）并切换到基于REDIRECT的规则，看看问题是否消失。 如果你可以粘贴你的REDIRECT或相关的iptables规则，这将是有帮助的。
Unix错误110意味着“连接超时”。 远程站点从未响应请求。
当我试图达到80.75.1.4时，我也无法达到它。 从ping和traceroute看来，进入伊朗之后，networking上有很大的数据包丢失。 这可能就是为什么网站没有回应。
$ traceroute 80.75.1.4 traceroute to 80.75.1.4 (80.75.1.4), 30 hops max, 60 byte packets 1 hosted.by.leaseweb.com (198.7.57.254) 1.275 ms 1.227 ms 1.888 ms 2 108.59.15.23 (108.59.15.23) 0.249 ms 0.243 ms 0.216 ms 3 be4.cr2.wdc1.leaseweb.net (108.59.15.108) 0.922 ms be3.cr2.wdc1.leaseweb.net (108.59.15.102) 0.922 ms ae1.cr1.wdc1.leaseweb.net (108.59.15.116) 0.275 ms 4 xe-7-2-0-690.edge1.Washington1.Level3.net (4.28.127.57) 1.258 ms xe-5-3-0-673.edge3.Washington1.Level3.net (4.59.144.161) 1.181 ms 1.247 ms 5 ae-4-90.edge1.Washington4.Level3.net (4.69.149.207) 1.779 ms 1.749 ms ae-3-80.edge1.Washington4.Level3.net (4.69.149.143) 1.670 ms 6 ash-bb1-link.telia.net (213.248.81.117) 1.499 ms ash-bb1-link.telia.net (213.248.89.177) 15.220 ms ash-bb1-link.telia.net (213.248.103.233) 1.505 ms 7 ash-bb4-link.telia.net (213.155.130.58) 1.560 ms 1.637 ms * 8 ldn-bb2-link.telia.net (80.91.246.67) 76.651 ms 76.782 ms 76.761 ms 9 ldn-b1-link.telia.net (80.91.248.93) 77.581 ms 77.552 ms 77.515 ms 10 telecominfra-ic-132493-ldn-b1.c.telia.net (213.248.76.42) 234.204 ms 233.666 ms 233.731 ms 11 * * * 12 * 10.10.53.222 (10.10.53.222) 251.938 ms * 13 217.11.30.246 (217.11.30.246) 250.353 ms 250.725 ms 250.322 ms 14 80.75.1.4 (80.75.1.4) 240.361 ms 240.269 ms 240.327 ms
更糟糕的是，在这条路上看起来有人在公共互联网上使用了RFC 1918地址。 除此之外，这会导致pathMTU发现中断，这意味着许多TCP连接也将中断。
引用一个来源， 思科的IP寻址最佳实践（PDF） ：
任何通过公共地址连接到networking区域的路由器到路由器链路都应使用公共IP地址进行寻址。 为networking的特定区域服务的路由器使用并且继续仅使用私有地址可以使用路由器到路由器链路上的私有地址。
这个要求启用并帮助确保pathMTU发现（RFC 1191）正常工作; 路由器必须能够发送“数据包过大”错误，并且必须确保数据包可能到达原始源主机。 如果路由器到路由器的链路使用RFC 1918地址进行寻址，则由路由器生成的Internet控制消息协议（ICMP）消息将来自RFC 1918地址。 使用RFC 1918源IP地址或使用单播反向path转发（uRPF）过滤出传入数据包的networking可能会丢弃这些数据包，从而使这些应用程序的TCP断开。 这将导致通过TCP连接的大数据包传输完全失败或性能不理想。
简而言之，这里存在多个networking问题，这将导致许多或大多数互联网用户无法访问该网站。
可能的问题可能是MTU，也可能是路由问题，因为你可以通过链接打开地址或者可能涉及到MTU的问题。
要检查MTU，您需要使用ping来检查正确的pathMTU，并手动将正确的MTU设置为您的networking适配器。 你也可以在你的iptables中使用Change-MSS来解决这个问题我尝试哟解释这两个解决scheme：
对于MTU检查尝试使用以下命令ping目标：
ping -M do -s 1472 <ip address>
-s argeument设置ping包的大小，你可以改变这个值（通常是减less），直到你发现ping的值，你的包开始被分割。 然后将28个字节（ping头大小）添加到此值，这是您的PMTU大小。 您也可以使用tracepath来发现PMTU。
那么你必须设置一个iptables规则来设置改变数据包MSS大小accourding到您的pathMTU大小。
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss <PMTU size>
你也可以使用--clamp-mss-to-pmtu来让iptables自动检查PMTU：
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
这就是我现在可以说的，希望它有帮助
PS您是否使用TProxy作为透明代理？