Logiconsole

游戏人

0%

终极翻墙攻略

发表于 分类于

好久没有更新文章了，是时候水一篇了。

翻墙了这么多年，前两天看到一个视频，标题是“如果翻墙有段位，你属于哪一梯队？”。嗯……不知不觉我已经是大佬段位了吗，可怕可怕。

那今天就分享一下我的翻墙方案，主要包括节点、客户端、全平台统一规则这几个方面。

节点

首先来看看那个视频里面给不同翻墙方案排的“段位”：

你现在是什么段位呢？

在两年前的时候，我还坚持自己搭建节点并且拒绝使用机场节点。先说说这两个方案的优缺点：

机场

  • 优点：
    • 节点多，总会有可用的节点（不包括一些劣质机场，看着很多节点，但其实所有中转节点或落地节点都是同一个）
    • 可以以相对较低的价格享受优质国内中转节点
    • 省心，不用自己处理节点被封、网络波动等问题
    • 有解锁各种服务的节点
    • 时不时被 D 狗攻击（D 狗死全家！！！）
  • 缺点：
    • 多人共用节点，IP 质量无法保证
    • 经常切换线路，登录经常弹验证码
    • 可能导致某些网站账号被封（比如 Facebook）

自建节点：优缺点基本上和机场完全相反

所以，我的方案自然而然进化到了机场+自建落地的混合方案，也就是所谓的 relay（链式代理），数据先经过机场节点，再经过自建节点（不过倒是不至于和截图中一样，还使用指纹浏览器，我又不是灰产……）这种方式有如下好处：

  • 用机场节点保护自建节点，防止自建节点被封
  • 对于被访问的服务和网站来说，我的 IP 始终是自建节点的 IP，不会因为机场节点切换而频繁变化
  • 优秀的机场节点可以拯救垃圾自建节点

当然，也有一个显而易见的缺点：翻墙路径多了一步，速度肯定会变慢。因此，我们需要分流，让一些需要固定 ip 进行访问的网站使用链式代理，其他的网站只使用机场节点就行了。

配置和规则

既然同时提到了链式代理和分流，那最有名的客户端方案就是 Clash 了。现在新的翻墙客户端和协议层出不穷，除了可以满足这些功能外，Clash 还有两个优势使我坚定地选择它：

  1. 客户端丰富，几乎全平台都有客户端、或兼容 clash 配置文件的客户端
  2. 可以导入在线规则，一次配置，所有客户端都可以使用

对于我这样的懒人来说，这两个优势太大了，让我可以减少很多折腾的时间。

说到在线规则，很多人都只会直接导入机场的订阅规则。部分用户会使用订阅转换、substore 等进阶方案。要我说，都不如 cloudflare worker 更实用。它不仅可以允许你使用 js 自定义规则，还能直接提供在线配置的托管功能。下面，我会把我的 cf worker 代码分享出来，并且说明其中一些关键代码段的作用。使用其他客户端、配置的用户也可以参考这个思路，写出适合自己的代码。

点击查看完整代码

主要需要配置的是前 71 行的代码，我已经把每一行的解释写在下面了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
/*
此处定义了数个机场订阅，其中第一个是你使用的主力机场
你还可以配置多个备用机场，包括不限时流量的机场。可以根据自己的情况删减。
在后面的代码中，会为它们分别生成一个代理组，
然后合并为一个最终代理组`自动选择`。
`自动选择`的type为`fallback`，
也就是只有当第一个机场所有节点不可用，才会切换为第二个机场。
之所以不使用`url-test`在所有机场的所有节点中选择延迟最低的节点，
是怕不经意间把贵的机场的流量、或者不限时流量给用完了。
如果你不担心这个问题，可以修改`自动选择`的type为`url-test`。

可以看到我还注释掉了一个`warp`的订阅。
这个订阅来自https://neko-warp.nloli.xyz，
使用cloudflare warp作为代理节点，是作为其他机场都失效时的兜底代理的。
但我自己实测后发现这个订阅的节点几乎处于不可用状态。
你可以自己取消注释（删除行首的`//`），看看是否可用。
*/
const subscribe_urls = [
    {
        name: "主力机场",
        url: "{隐藏}",
    },
    {
        name: "备用机场1",
        url: "{隐藏}",
    },
    {
        name: "备用机场2（不限时流量）",
        url: "{隐藏}",
    },
    {
        name: "备用机场3",
        url: "{隐藏}",
    },
    // { name: "warp", url: "https://neko-warp.nloli.xyz/neko_warp.yaml" },
];

/*
此处定义了固定IP代理应该使用哪些机场。
脚本会挑选这些机场中延迟最低的节点，
生成一个`zzzAUTO-STATIC`代理组，
再和自建节点一起生成`PROXY-STATIC`这个链式代理组。
这里我使用了所有可用机场，
并且代理组的type为`url-test`，
因为需要走固定IP代理访问的地址通常都不会用掉太多流量。
*/
const static_providers = [
    "主力机场",
    "备用机场1",
    "备用机场2（不限时流量）",
    "备用机场3",
];

/*
此处定义了观看EMBY应该使用哪些机场。
众所周知，现在有很多机场提供EMBY专用的节点。
你可以把拥有这种节点的机场加进来。
如果你的机场没有这种节点，但这个机场流量不贵，也可以加进来。
这里我就没有添加不限时流量的机场。
*/
const emby_providers = ["主力机场", "备用机场1", "备用机场3"];

/*
排除节点的规则，满足这些规则的节点不会被使用。
还排除了一些高倍率节点，即`| [1-9]\\d*(\\.\\d+)*[倍xX]`部分。
你可以按需删除或修改。
*/
const exclude_filter =
    "(?i)过期|到期|剩余|重置|TG群|劫持|专用|官网|订阅|IPV6| [1-9]\\d*(\\.\\d+)*[倍xX]";

/*
低倍率节点的规则。
因为很多机场的低倍率节点质量都比较差，这些节点也会被排除。
如果你不想要排除，可以把引号中间的内容去掉。
*/
const low_ratio_filter = "0\\.\\d+[倍xX]";

/*
自建节点的名字，对应的配置在下面的proxies里面。
*/
const landing_proxy = "甲骨文日本";

/*
测试固定IP代理中所有节点延迟的url，
我们希望机场的节点到自建节点的速度越快越好。
推荐在自建节点上放一个可访问的http链接
（如果搭建的代理类型有伪装网站，那么伪装网站的链接就是不错的选择）
*/
const url_test_static = "{隐藏}";

/*
测试观看EMBY时所有节点延迟的url，
我们希望机场的节点到EMBY服务器的速度越快越好。
推荐使用EMBY服务器的favicon.ico链接。
如果你不看EMBY，此处可以设置为http://1.1.1.1/generate_204
*/
const url_test_emby = "{隐藏}/web/favicon.ico";

/*
切换节点的阈值。
只有当新节点延迟比正在使用的节点低至少30ms，才会切换。
防止频繁切换节点
*/
const tolerance = "30";

/*
EMBY专用节点的匹配规则
*/
const emby_filter = "(?i)过期|SP|[Ee]mby";

/*
自定义分流规则
*/
const custom_rules = `
  ### google play
  - DOMAIN-SUFFIX,googleapis.cn,PROXY
`;

/*
作为替代neko-warp的方案，我使用了
https://github.com/yonggekkk/Cloudflare_vless_trojan提供的代码，
再创建一个cloudflare worker，生成一个vless节点，即下方的CF节点。
如果你不使用这个方法，可以删除这部分代码，同时修改76行，把
`PROXY: { type: "select", proxies: ["自动选择", "CF"] },`
改为：
`PROXY: { type: "select", proxies: ["自动选择"] },`
*/
const proxies = `
proxies:
  - name: "甲骨文日本"
    type: vmess
    server: {隐藏}
    port: 443
    uuid: {隐藏}
    alterId: 0
    cipher: aes-128-gcm
    udp: true
    tls: true
    skip-cert-verify: true
    servername: {隐藏}
    network: ws
    ws-opts:
      path: {隐藏}
      headers:
        Host: {隐藏}
  - name: "CF"
    type: vless
    server: {隐藏}
    port: {隐藏}
    uuid: {隐藏}
    network: ws
    tls: false
    udp: false
    sni: {隐藏}
    client-fingerprint: chrome
    ws-opts:
      path: {隐藏}
      headers:
        host: {隐藏}
`;

/*
尽可能隐藏托管配置文件的url。
实际托管地址为
https://你的cloudflare-worker地址/?q={query_param}
*/
const query_param = "{隐藏}";

值得需要注意的一些地方：

  • EMBY 代理组多加了一个"DIRECT"代理，假如你的 EMBY 服务器直连最快，会使用直连方式连接。
  • 如果你有更严格的防 DNS 泄露需求，可以自行修改脚本下方settings的部分。
  • 同样是settings的部分，如果你需要使用 ipv6，请自行修改。
  • 常见的需要使用固定 IP 访问的网站都已经加进了脚本下方的rules部分，你可以通过上面的custom_rules补充。
  • 规则组主要来自于blackmatrix7 的规则，你也可以在脚本下方rule_providers中补充。
  • 通用测速地址为http://1.1.1.1/generate_204，使用 IP 地址，防止被机场劫持。

在 Cloudflare Worker 中新建一个 Worker，把修改后的完整代码粘贴进去即可。

在 Clash 中导入在线订阅地址https://你的cloudflare-worker地址/?q={query_param}，即可使用该配置。下面是我的 Clash 中的截图：

其中，PROXY 默认为自动选择，也可以手动选择任意机场。进入下面某个机场的列表，也可以选择机场中的某个节点（仅当 PROXY 手动选择机场时生效，因为自动选择时，使用的是自动测速获得的节点）

很多中间步骤的代理组都隐藏了，比如zzzAUTO-STATIC代理组，因为设置了hidden = true，在大部分最新的客户端中都是会被隐藏的。

客户端

这个配置适用于任何使用 clash meta 内核的客户端。作为参考，下面是我正在使用的客户端：

  • 家中，openclash 运行在路由器/软路由上
  • Android: FlClash
  • Windows: Clash Verge

其他客户端请自行搜索。