V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
爱意满满的作品展示区。
breakwa11
V2EX  ›  分享创造

GFW 专用白名单列表

  •  
  •   breakwa11 ·
    breakwa11 · 2014-10-17 01:05:37 +08:00 · 7647 次点击
    这是一个创建于 3672 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我写了一个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'
    

    求改进意见

    第 1 条附言  ·  2014-10-22 11:22:32 +08:00
    增加了一个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上似乎表现得更理想,求更多的实际使用测试
    26 条回复    2014-11-12 01:03:41 +08:00
    pierrec
        1
    pierrec  
       2014-10-17 02:17:49 +08:00
    cow比较好用,list不用全部更新,需要就自动加进去,长期不访问就删除 挺好
    Tink
        2
    Tink  
       2014-10-17 02:23:58 +08:00
    apple.com 和 amazon.com是走墙内还是墙外
    breakwa11
        3
    breakwa11  
    OP
       2014-10-17 02:34:48 +08:00   ❤️ 1
    @Tink 走代理,只加了国内的域名
    breakwa11
        4
    breakwa11  
    OP
       2014-10-17 02:35:20 +08:00
    @pierrecpen pac怎么实现cow?
    pierrec
        5
    pierrec  
       2014-10-17 02:38:00 +08:00
    @breakwa11 ios mac不清楚 (估计把cow部署在国内服务器上就可以用)
    pc

    # HTTP (提供 http 代理):
    # listen = http://127.0.0.1:7777
    #
    # 上面的例子中,cow 生成的 PAC url 为 http://127.0.0.1:7777/pac
    pierrec
        6
    pierrec  
       2014-10-17 02:40:14 +08:00
    @breakwa11 cow是检测墙了,自动添加list,白名单维护成本太高,可以效仿cow模式?
    breakwa11
        7
    breakwa11  
    OP
       2014-10-17 02:46:07 +08:00
    @pierrecpen 但是服务器根本不知道客户端访问了什么
    hzlzh
        8
    hzlzh  
       2014-10-17 02:47:12 +08:00
    可以收录一下:hzlzh.com 墙了好几年了
    breakwa11
        9
    breakwa11  
    OP
       2014-10-17 02:51:16 +08:00
    @hzlzh 这是白名单,收录的是没有被墙的域名
    changsha
        10
    changsha  
       2014-10-17 07:19:37 +08:00 via iPhone
    白名单....太多l q
    zeroday
        11
    zeroday  
       2014-10-17 13:01:54 +08:00


    测试时,发现这个被墙,
    anyfc
        12
    anyfc  
       2014-10-17 15:19:48 +08:00
    一万4千多条。。。
    breakwa11
        13
    breakwa11  
    OP
       2014-10-17 15:52:16 +08:00
    @zeroday 这个是啥?

    @anyfc 等数据收集的差不多了再从中过滤出较常用的就会好多了
    zeroday
        14
    zeroday  
       2014-10-17 17:19:31 +08:00
    breakwa11
        15
    breakwa11  
    OP
       2014-10-17 18:01:03 +08:00
    @zeroday 这域名并不在列表里,所以应该代理连接啊,我访问这个没有问题。你用黑名单列表没有把那个域名加在你自己的列表吧?
    Actrace
        16
    Actrace  
       2014-10-19 23:40:25 +08:00
    国内大多数视频网站的资源地址都是直接用服务器IP的...
    breakwa11
        17
    breakwa11  
    OP
       2014-10-20 09:58:04 +08:00
    @Actrace pac代码里对于ip都是直连的
    Actrace
        18
    Actrace  
       2014-10-20 10:02:30 +08:00
    @breakwa11 这样一刀切不太好吧..如果有一些IP也是需要翻出去的话...
    breakwa11
        19
    breakwa11  
    OP
       2014-10-20 11:47:05 +08:00
    @Actrace 对于这个我有搜索过现成的黑名单列表,发现没有独立的ip条目,所以似乎目前没有设置的必要,国外常见的视频网站都不像国内这样直接用ip,都带有域名的。如果真出现ip访问而那个ip被屏蔽的情况,那么以目前pac的执行性能,也并不合适做精确的国内ip匹配。

    我自己目前的方案是白名单直连(我在维护这个白名单),黑名单用代理,均不在的使用动态代理。如果发现真有ip是有这种情况,那么把这个pac里匹配ip的代码去掉即可。黑白名单主要用来提升动态代理的执行性能。
    breakwa11
        20
    breakwa11  
    OP
       2014-10-22 15:15:25 +08:00
    @xream @usufu @SoloCompany @Leask 综合了以上几位大牛的研究成果,构造了新的IP段查询算法,以O(1)的查询效率比原来二分查询要快两个数量级

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

    chrome:
    whitelist.pac 63ms
    whiteiplist.pac 90ms
    breakwa11
        21
    breakwa11  
    OP
       2014-10-23 14:17:40 +08:00
    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
        22
    breakwa11  
    OP
       2014-10-23 16:31:25 +08:00
    fakeip的查询效率没有多少影响,之后就不单独测试了

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

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

    因为chrome的表现好,所以就没有针对chrome做更多的优化,而倾向于让firefox得到更好的效果
    Leask
        23
    Leask  
       2014-11-05 02:00:03 +08:00
    这个表太暴力了!居然全部列出来了。哈哈。不过我有一点疑问,这样暴力地展开数据,虽然查询效率能在数学上达到 O(1),但是内存的开销较大。如果作为全局 pac 来用,每次查询之前,内存都需要建立一个 hash 表,会有不小消耗,况且建立 hash 其实也会消耗时间,所以单单比较查询时间,可能还不够。不过,依然很好玩,赞一个!
    breakwa11
        24
    breakwa11  
    OP
       2014-11-11 00:52:47 +08:00
    版本更新,最近想到了一个新的优化,大幅降低了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
        25
    Leask  
       2014-11-11 21:14:20 +08:00
    @breakwa11 当然,我只是在技术上对比开销,即使现在任何一个方案在复杂度再上一个数量级,人类还是体验不到流畅度改变。我之前只是针对你只对比查询速度,而不考虑内存的开销和建立查询的准备工作的开销,是不严谨的,这样会让我觉得在看那些评测软文。不过这并不代表你的优化没有意义,不要误会,哈哈,谢谢你的努力。我平时只用 Safari 和 Chrome,他们都会缓冲 dns 结果。而且在合理的浏览器实现中,dnsResolve 应该不占用任何时间才对,因为 http 请求过程中无论如何你都需要先做一次 dns 查询,只是放在前面还是放在后面而已。看你的描述,我觉得是 Safari 的 bug 了。
    breakwa11
        26
    breakwa11  
    OP
       2014-11-12 01:03:41 +08:00
    @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那台机子的压力
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2976 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:41 · PVG 22:41 · LAX 06:41 · JFK 09:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.