优化前后对比#
测试时间为晚上18:00，算晚高峰时间段了。
优化前：
优化后：
虚拟主机反向代理#
使用虚拟主机进行反向代理，效果类似于 CDN。之所以不直接使用 CDN，主要原因在于 CDN 节点分布在各地，而 Cloudflare 使用的是 Anycast IP，虽然每个 IP 对应一定数量的节点（相对固定），但不同的 IP 回源速度差异较大。有些 IP 的回源速度较快，而有些则较慢。因此，找到一个所有节点都表现优异的 Anycast IP 是非常困难的，使用固定 IP 通常能提供更稳定的性能。
在淘宝我发现了这家，拥有30M的带宽，IP是腾讯云的，一个月2块，一年20，50G流量对于大部分个人用户来说也够用了。
在虚拟主机设置伪静态，如果是宝塔面板，则使用nginx规则，如果是kangle面板，则使用Apache的规则。
Nginx规则：
1
2
3
4
|
location ^~ / {
proxy_ssl_server_name on;
proxy_pass http://xxx.xxx.xx; # tunnel中绑定的域名
}
|
Apache规则：
1
2
|
RewriteEngine On
RewriteRule ^(.*)$ https://xxx.xxx.xx/$1 [P]
|
优化后：
虚拟主机反向代理优化#
优选IP（效果好！）#
进行这一步的主要原因是在上一步的反向代理配置后，网站出现了断流现象——即每隔一段时间就会突然变得非常慢，然后又恢复正常。推测这是由于 Cloudflare 回源的不稳定所导致的。可以手动选择一些表现更好的 Anycast IP，具体可以搜索一些 Cloudflare 香港段的 IP 测试或者移动网络的优选 IP。
目前只研究了Nginx版本：
1
2
3
4
5
|
location ^~ / {
# proxy_ssl_server_name on; # 优选可以不用开启
proxy_pass http://172.64.32.1; // 填写优选IP
proxy_set_header Host xxx.xxx.xx; // 填写tunnel中绑定的域名
}
|
开启websocket支持#
1
2
3
4
5
6
7
8
9
10
|
location ^~ / {
proxy_pass http://172.64.32.1;
proxy_http_version 1.1; # 设置 HTTP 协议版本
proxy_set_header Upgrade $http_upgrade; # 转发 WebSocket 升级头
proxy_set_header Connection $http_connection; # 保持 WebSocket 连接的升级
proxy_cache_bypass $http_upgrade; # 确保 WebSocket 连接不被缓存
proxy_set_header Host $target_host;
}
|
子域名自动转发#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
location ^~ / {
proxy_pass http://172.64.32.1;
set $target_host default.xxx.xx;
if ($host ~* "^(?<subdomain>\w+)\.imbai\.xin$") {
set $target_host $subdomain.xxx.xx;
}
if ($host = 'comment.imbai.xin') {
set $target_host twikoo.xxx.xx;
}
proxy_set_header Host $target_host;
}
|
最终版#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
location ^~ / {
proxy_pass http://172.64.32.1;
set $target_host fresh.031228.xyz;
if ($host ~* "^(?<subdomain>\w+)\.imbai\.xin$") {
set $target_host $subdomain.031228.xyz;
}
if ($host = 'comment.imbai.xin') {
set $target_host twikoo.031228.xyz;
}
proxy_http_version 1.1; # 设置 HTTP 协议版本
proxy_set_header Upgrade $http_upgrade; # 转发 WebSocket 升级头
proxy_set_header Connection $http_connection; # 保持 WebSocket 连接的升级
proxy_cache_bypass $http_upgrade; # 确保 WebSocket 连接不被缓存
proxy_set_header Host $target_host;
}
|
添加前置代理（家宽推荐）#
Cloudflare Tunnel会解析region1.v2.argotunnel.com和region2.v2.argotunnel.com的DNS记录（默认v4，且ip均为美国），并使用cftunnel.com的SNI去连接到EndPoint。http2协议使用h2.cftuunel.com，quic协议使用quic.cftunnel.com，但是这两个域名本身并没有A和AAAA的DNS记录。
对这两个域名进行ping，延迟都在100ms以上。
随机选择一个IP进行测试（丢包率8%，平均延迟396ms）：
这是优化的第一步，优化连接到CloudFlare数据中心的链路。CloudFlare官方表示为了支持QUIC协议，无法支持socks5和http代理。Cloudflared tunnel via proxy · Issue #350 · cloudflare/cloudflared
只能使用VPN工具开启TUN模式或者在路由器上开启VPN对流量进行代理，这样就能使用机场的节点对流量进行代理。如果发现还是连接到了美国节点，可以添加一条目标端口为7844走代理的规则。
对于目前常用的协议测试了一下支持性：
| 协议 |
http2 |
quic |
| vmess |
x |
√ |
| ss |
x |
x |
| trojan |
x |
√ |
| Hysteria2 |
√ |
√ |
| vless |
x |
√ |
这个结果挺遗憾的，大部分低延迟中转机场使用的都是ss协议，而ss协议又无法为之所用。
优化后：
连接IP优选（效果不明显，不推荐）#
由于校园网可以直接连接到Cloudflare Tunnel的香港节点，且延迟非常低，仅50ms，因此可以考虑直接进行连接。
前面提到过，Cloudflare Tunnel会解析region1.v2.argotunnel.com和region2.v2.argotunnel.com的DNS记录，并通过cftunnel.com的SNI来连接到端点。
对于Region1，IP地址在198.41.192.0/24和2606:4700:a0::/48的地址段内；Region2的IP地址则位于198.41.200.0/24和2606:4700:a8::/48段内。
可以使用CloudflareSpeedTest工具对这些IP进行优选，从而选择最优的连接节点。
1
2
3
4
5
6
7
8
9
10
|
# region1
CloudflareST.exe -ip 198.41.192.0/24 -dd -allip -tp 7844
# region2
CloudflareST.exe -ip 198.41.200.0/24 -dd -allip -tp 7844
# ipv6
# region1
CloudflareST.exe -ip 2606:4700:a0::/48 -dd -allip -tp 7844
# region2
CloudflareST.exe -ip 2606:4700:a8::/48 -dd -allip -tp 7844
|
得到测试结果后，可以将最佳IP地址写入hosts文件，例如：
1
2
3
4
5
|
2606:4700:a0:cf86:818c:516:545a:b3a2 region1.v2.argotunnel.com
2606:4700:a0:8b22:56fa:6e68:8009:88e0 region1.v2.argotunnel.com
2606:4700:a8:b332:dce0:eb14:4750:4718 region2.v2.argotunnel.com
2606:4700:a8:9af6:73c8:6f8a:d06d:c59 region2.v2.argotunnel.com
|
通过这种方式，可以将延迟从大约60ms优化到50ms，提升幅度不大，还很折腾，不是很建议。