GFW 专用白名单列表

[breakwa11]

我写了一个Spider，自动收录常见国内网站域名作为白名单，国外自动使用代理，这样规则就不需要经常维护了。特别适合iOS自动代理配置和PC浏览器使用。而部分不需要代理且经常上的国外网站，需要手工加入列表。

由于使用域名匹配，DNS被污染也能正常使用。

列表地址

https://github.com/breakwa11/gfw_whitelist/blob/master/whitelist.pac

项目地址

https://github.com/breakwa11/gfw_whitelist

使用方法

下载 whitelist.pac 文件后，修改代理服务器的 ip 地址和代理类型。然后将浏览器的代理设置中指向 whitelist.pac

var proxy = 'PROXY www.abc.com:443'; // 需要更换成有效的代理地址，代理类型还可以为'SOCKS5'或'HTTPS'

求改进意见

增加了一个IP白名单，即国内IP列表，使用了我自己的查询优化算法，查询效率非常快，O(1)时间复杂度
列表地址
https://github.com/breakwa11/gfw_whitelist/blob/master/whiteiplist.pac

性能实测100,000次查询：
firefox:
whitelist.pac 51ms
whiteiplist.pac 109ms

chrome:
whitelist.pac 108ms
whiteiplist.pac 430ms

而whiteiplist.pac比相同作用的flora_pac快至少30倍（ff:28s, ch:14s），并且是精确IP匹配
另外使用whiteiplist时，你需要确认你已经解决DNS污染的问题
从数据上看在chrome上执行时间更长些，但实际使用的时候chrome上似乎表现得更理想，求更多的实际使用测试

[gqfBzoLVY3Wl4Tng]

cow比较好用，list不用全部更新，需要就自动加进去，长期不访问就删除 挺好

[Tink]

像 apple.com 和 amazon.com是走墙内还是墙外

[breakwa11]

@Tink 走代理，只加了国内的域名

[breakwa11]

@pierrecpen pac怎么实现cow？

[gqfBzoLVY3Wl4Tng]

@breakwa11 ios mac不清楚 (估计把cow部署在国内服务器上就可以用)
pc

# HTTP (提供 http 代理):
# listen = http://127.0.0.1:7777
#
# 上面的例子中，cow 生成的 PAC url 为 http://127.0.0.1:7777/pac

[gqfBzoLVY3Wl4Tng]

@breakwa11 cow是检测墙了，自动添加list,白名单维护成本太高，可以效仿cow模式？

[breakwa11]

@pierrecpen 但是服务器根本不知道客户端访问了什么

[hzlzh]

可以收录一下：hzlzh.com 墙了好几年了

[breakwa11]

@hzlzh 这是白名单，收录的是没有被墙的域名

[changsha]

白名单....太多l q

[zeroday]

测试时，发现这个被墙，

[anyfc]

一万4千多条。。。

[breakwa11]

@zeroday 这个是啥？

@anyfc 等数据收集的差不多了再从中过滤出较常用的就会好多了

[zeroday]

@breakwa11 http://imgur.com/

这个网站。

[breakwa11]

@zeroday 这域名并不在列表里，所以应该代理连接啊，我访问这个没有问题。你用黑名单列表没有把那个域名加在你自己的列表吧？

[Actrace]

国内大多数视频网站的资源地址都是直接用服务器IP的...

[breakwa11]

@Actrace pac代码里对于ip都是直连的

[Actrace]

@breakwa11 这样一刀切不太好吧..如果有一些IP也是需要翻出去的话...

[breakwa11]

@Actrace 对于这个我有搜索过现成的黑名单列表，发现没有独立的ip条目，所以似乎目前没有设置的必要，国外常见的视频网站都不像国内这样直接用ip，都带有域名的。如果真出现ip访问而那个ip被屏蔽的情况，那么以目前pac的执行性能，也并不合适做精确的国内ip匹配。

我自己目前的方案是白名单直连（我在维护这个白名单），黑名单用代理，均不在的使用动态代理。如果发现真有ip是有这种情况，那么把这个pac里匹配ip的代码去掉即可。黑白名单主要用来提升动态代理的执行性能。

[breakwa11]

@xream @usufu @SoloCompany @Leask 综合了以上几位大牛的研究成果，构造了新的IP段查询算法，以O(1)的查询效率比原来二分查询要快两个数量级

代码刚才调整了一下，新的测试结果（100,000次查询）：
firefox:
whitelist.pac 57ms
whiteiplist.pac 77ms

chrome:
whitelist.pac 63ms
whiteiplist.pac 90ms

[breakwa11]

whitelist加了少许优化，whiteiplist加入了fakeip，以抵抗一定程度的DNS污染，不过时间略微增加。
可根据个人环境自行选择使不使用fakeip

新的测试结果（100,000次查询）：
firefox:
whitelist.pac 53ms
whiteiplist.pac 77ms (no fake ip)
whiteiplist.pac 95ms (with fake ip)

chrome:
whitelist.pac 53ms
whiteiplist.pac 90ms (no fake ip)
whiteiplist.pac 110ms (with fake ip)

另外现在whitelist经过几轮迭代后，已经集中了大部分常见网站了
下期目标，生成在线订阅列表（像gfwlist那样的），然后浏览器代理插件可以定时自动更新，配置代理就更灵活了（不过性能上可能不如直接使用pac）

球关注ლ(╹◡╹ლ)

[breakwa11]

fakeip的查询效率没有多少影响，之后就不单独测试了

另外要说一声对不起的是，之前的测试版本有BUG，会导致错判，结果无效，以以下的结果为准
新的测试结果（100,000次查询）：
firefox:
whitelist.pac 53ms
whiteiplist.pac 81ms

chrome:
whitelist.pac 53ms
whiteiplist.pac 649ms

因为chrome的表现好，所以就没有针对chrome做更多的优化，而倾向于让firefox得到更好的效果

[Leask]

这个表太暴力了！居然全部列出来了。哈哈。不过我有一点疑问，这样暴力地展开数据，虽然查询效率能在数学上达到 O(1),但是内存的开销较大。如果作为全局 pac 来用，每次查询之前，内存都需要建立一个 hash 表，会有不小消耗，况且建立 hash 其实也会消耗时间，所以单单比较查询时间，可能还不够。不过，依然很好玩，赞一个！

[breakwa11]

版本更新，最近想到了一个新的优化，大幅降低了iplist在chrome的查询速度，同时firefox也有少许的速度优化
以下是新的测试结果（100,000次查询，其中whitelist包含23,000条数据）：
firefox:
whitelist.pac 55ms
whiteiplist.pac 75ms

chrome:
whitelist.pac 53ms
whiteiplist.pac 230ms
结果表明，whitelist中的数据条数与运行时间之间的关系非常小
而whiteiplist经过调整数据，在不降低查询精度的情况下，减少了近60%的查询量


@Leask 其实因为whiteiplist一定比whitelist小，不管文件大小还是加载后占用的内存，所以只要whitelist在性能上没有问题，那么whiteiplist也肯定没有问题。而whitelist在浏览器里，如果只单独运行一次（让浏览器没有预加载）的情况下，平均不到1ms，那就是说即使浏览器不对pac做任何的缓冲，1秒也能没有压力查询至少1000次，平时的应用根本成为不了效率瓶颈（何况SwitchySharp的pac比这还要慢一千倍在一般情况下都没感觉有多大问题）。至于内存，别看它看起来很长，再怎么样也占用不到1M内存的（SwitchySharp的pac比这还要大上不少）。不过其实最大的问题存在于pac里的dnsResolve函数，firefox+foxyproxy配置下，firefox经常因为dnsResolve执行缓慢而假死，似乎是firefox对于相同的域名会反复查询无缓存，而chrome下一点问题都没有，我只好firefox用whitelist，在chrome用whiteiplist。这个问题我一直没有能解决，不知道你有没有遇到同样的问题？

[Leask]

@breakwa11 当然，我只是在技术上对比开销，即使现在任何一个方案在复杂度再上一个数量级，人类还是体验不到流畅度改变。我之前只是针对你只对比查询速度，而不考虑内存的开销和建立查询的准备工作的开销，是不严谨的，这样会让我觉得在看那些评测软文。不过这并不代表你的优化没有意义，不要误会，哈哈，谢谢你的努力。我平时只用 Safari 和 Chrome，他们都会缓冲 dns 结果。而且在合理的浏览器实现中，dnsResolve 应该不占用任何时间才对，因为 http 请求过程中无论如何你都需要先做一次 dns 查询，只是放在前面还是放在后面而已。看你的描述，我觉得是 Safari 的 bug 了。

[breakwa11]

@Leask iOS系统的话，mac我手上没有，在ipad上使用没有问题，打开AppStore快多了。我开启一个pdnsd来缓存结果后，firefox就明显好多了，说明firefox+foxyproxy配置下并没有对DNS的结果做缓存。不过内存开销那些实在不容易测试（相对于浏览器一打开就是几百M内存，这不到1M的空间实在没法感觉到），所以改用单次查询的测试，若单次查询不会大于10ms，那么实际使用基本不会感觉出来。而库中有一个pactest，用的那个测试库没有DNS缓冲，于是存在dnsResolve的时候单次查询都要几毫秒，且误差较大，难以对比其它部分的效率，且不同浏览器解析pac的效率都不相同，于是只保留了在浏览器上测试的结果，这个数据更能反映实际的情况。

我安装了Safari on windows做了一下测试：
whitelist.pac 119ms
whiteiplist.pac 124ms

还有IE9：
whitelist.pac 55ms
whiteiplist.pac 140ms

想不通为啥whiteiplist是chrome最慢了。不过whitelist倒是Safari最慢，但Safari的执行速度似乎最为稳定

另外新加了一个混合列表，参考自 @usufu 的实现，加入了域名黑白名单，简化了一下GFWList2PAC的实现，现在这个新list的实用性就相当好了，可以配置黑白名单分别用什么代理，而不在这两个名单的又用什么代理（比如可以用COW），这样在局域网多人共用的话，可以很有效降低COW那台机子的压力