当 squid 设置为 TPROXY 时，在某些站点上会返回 ERR_CONNECT_FAIL。运行 squid 的服务器能够通过 lynx、wget、curl 等打开这些站点。即使我们在浏览器中手动设置代理或使用简单的 REDIRECT 或 DST-NAT，这些站点也可以打开。
从此页面http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
它会导致路径 MTU (PMTUD) 失败，可能导致一些远程站点无法访问。如果您的客户端计算机通过以太网或 DSL PPPoATM 连接，并且缓存和客户端之间的所有链路的 MTU 为 1500 或更高，则这通常不是问题。如果您的客户端通过 DSL PPPoE 连接，那么这可能是一个问题，因为 PPPoE 链路通常具有较低的 MTU（1472 非常常见）。
但我的以太网也有同样的问题
以下是来自一个客户端的 tcpdump：
点击此处查看我使用 tproxy 时出现的 tcpdump 问题
和
单击此处查看 tcpdump，当我在浏览器中手动设置代理时，一切正常
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 执行
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 执行
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
跟踪路由 --mtu 80.75.1.4
traceroute to 80.75.1.4 (80.75.1.4), 30 hops max, 65000 byte packets
1 x.x.x.10 (x.x.x.10) 0.820 ms F=1500 0.681 ms 0.243 ms
2 y.y.y.1 (y.y.y.1) 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 *
跟踪路径 80.75.1.4
1: cache.mysquid.com 0.092ms pmtu 1500
1: x.x.x.10 0.380ms
1: x.x.x.10 0.309ms
2: y.y.y.1 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
我不知道是否相关，但我也有以下配置
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 隧道进行的。
答案1
从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)
x.x.x.150.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)
x.x.x.150.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)
x.x.x.150.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)
x.x.x.150.62568 > 80.75.1.4.80: Flags [R], cksum 0xa779 (correct), seq 572035650, win 0, length 0
这似乎不是 MTU 问题。要开始进行故障排除，我建议删除TPROXY（假设您正在使用它）并切换到REDIRECT基于规则，看看问题是否消失。如果您可以粘贴您的REDIRECT或相关的 iptables 规则，那将会很有帮助。
答案2
Unix 错误 110 表示“连接超时”。远程站点从未响应该请求。
当我尝试访问 80.75.1.4 时，我也无法访问它。从图中可以看出，ping进入traceroute伊朗境内后，网络上出现了大量数据包丢失。这可能是该网站无法响应的原因。
$ 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 地址。除其他外，这会导致路径 MTU 发现中断，这意味着许多 TCP 连接也会中断。
引用一个来源的话，Cisco 的 IP 寻址最佳实践 (PDF)：
任何连接到具有公共地址的网络区域的路由器到路由器链路都应使用公共 IP 地址。服务于使用并继续使用私有地址的特定网络区域的路由器可以在路由器到路由器链路上使用私有地址。
此要求可实现并有助于确保路径 MTU 发现 (RFC 1191) 正常工作；路由器必须能够发送“数据包过大”错误，并且必须确保数据包很可能到达原始源主机。如果路由器到路由器的链路使用 RFC 1918 地址寻址，则路由器生成的 Internet 控制消息协议 (ICMP) 消息将来自 RFC 1918 地址。使用 RFC 1918 源 IP 地址过滤传入数据包或使用单播反向路径转发 (uRPF) 的网络可能会丢弃这些数据包，从而破坏这些应用程序的 TCP。这将导致通过 TCP 连接传输大数据包完全失败或性能不佳。
简而言之，这里存在多个网络问题，会导致许多或大多数互联网用户无法访问该网站。
答案3
可能的问题可能是 MTU 和路由问题，因为您可以通过链接或 curl 打开地址，问题可能与 MTU 有关。
要检查 MTU，您需要使用 ping 检查正确的路径 MTU，并手动为网络适配器设置正确的 MTU。您也可以在 iptables 中使用 Change-MSS 来解决此问题，我尝试解释这两种解决方案：
对于 MTU 检查，请尝试使用以下命令 ping 目标：
ping -M do -s 1472 <ip address>
-s 参数设置 ping 包大小，您可以改变该值（通常减小）直到您发现 ping 包的值开始出现碎片。然后将 28 字节（ping 头大小）添加到该值，这就是您的 PMTU 大小。您也可以使用它tracepath来发现 PMTU。
然后您必须设置一个 iptables 规则来根据路径 MTU 大小设置更改数据包的 MSS 大小。
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss <PMTU size>
您还可以使用--clamp-mss-to-pmtuiptables 自动检查 PMTU：
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
这就是我现在能说的全部内容，希望对您有所帮助
PS 您使用 TProxy 进行透明代理吗？