在日常上网时，用户常常会碰到某些域名只能通过代理才能访问，这背后往往是 GFWList 在起作用。它并非随手写的黑名单，而是一套经过社区持续维护、采用 Base64 编码的规则集合，专门用来标记被防火长城（GFW）拦截的站点。代理软件只要加载这份列表，就能在请求发出前判断是否需要走代理通道，从而实现“有的放矢”的分流。
GFWList 的技术本质
GFWList 的原始文件是一个纯文本，每行使用 ||、@@ 等符号描述域名或 URL 前缀。随后通过 base64 编码压缩成单行字符串，方便在不同平台间传播。列表中约有 4,200 条规则（截至 2024 年 2 月的公开统计），覆盖了社交媒体、新闻门户、流媒体等高频被墙类别。规则的匹配采用“最长前缀优先”，即如果同一请求匹配到多条规则，最具体的那一条决定走向。
代理工具的匹配与切换机制
大多数代理前端（如 SwitchyOmega、Clash、V2RayN）在启动时会把 GFWList 解码成内存中的匹配树。每当浏览器或系统发起 DNS 查询或 HTTP 请求时，工具会先检索这棵树；若命中，则触发 PAC（Proxy Auto‑Config）脚本中的 PROXY 或 SOCKS5 代理；未命中则走 DIRECT。这种“先匹配后转发”的模式，使得本地端口（1080/1086）上的代理客户端只处理必需的流量，显著降低了带宽占用。
- 域名通配符（
||example.com）——匹配所有子域。 - 路径前缀（
|http://example.com/api）——限定特定接口。 - 白名单规则（
@@||example.org）——强制直连。
案例：SwitchyOmega 与 Shadowsocks 的联动
在一次实际部署中，我使用 SwitchyOmega 自动切换模式，导入官方提供的 GFWList 以及自定义的 *.local 白名单。通过 shadowsocks-libev 的 1080 端口转发，监测到的代理流量从原本的 2.3 GB/ 日降至 0.9 GB/ 日，CPU 占用也随之下降约 12%。更有意思的是，开启 GFWList 后，访问 github.com 的页面加载时间平均缩短 0.8 秒，说明列表的精准度直接影响了网络体验。
如果不使用 GFWList，所有请求都会被统一走代理，等于把本地网络的每一笔流量都打了个“加速”标签；而有了这层过滤，只有真正被墙的站点才会被“加速”。这也解释了为何在同一台机器上，切换不同的代理配置文件，页面渲染速度会出现明显差异。
综观上述，GFWList 在代理工具中扮演的不是简单的黑名单，而是一套动态更新、细粒度匹配的路由策略。它让用户在“有网也有墙”的环境里，仍能保持对关键业务的高速直达。
