嘿嘿,还是一如既往地懒,直接把 Github 上的 README.md 贴上来吧。
Github地址: https://github.com/wspl/CIDR2PAC
(欢迎 Star、Fork、做 PAC 镜像)
A es6 script for covering CIDRs list to PAC proxy script.
一个用于将 CIDR 列表文件转换为 PAC 自动代理文件的脚本。
中国IP段CIDR列表地址:(项目中已自带)
http://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone
// 安装 io.js 与 npm
// 根据需求修改 index.js 文件中的 CIDR_PATH / PAC_PATH / PROXY 三个常量
$ git clone https://github.com/wspl/CIDR2PAC.git
$ cd ./CIDR2PAC
$ npm install
$ iojs ./
// 然后就可以在 PAC_PATH 对应目录找到你的 PAC 文件。
该 PAC 文件将使国内 IP 网站跳过代理,非国内 IP 网站走 127.0.0.1:1080
的代理。
Github Raw: https://raw.githubusercontent.com/wspl/CIDR2PAC/master/whitelist.pac
(可以直接贴到浏览器代理设置的 pac 地址栏中,当然首先得能访问 Github _(:з」∠)_)
1
goodbest 2015-08-04 21:57:50 +08:00
如果没有靠谱的DNS,碰到DNS污染,这些都是白搭啊...
|
2
LazyZhu 2015-08-04 22:03:10 +08:00
@plqws
CIDR可以直接从apnic抓 wget -O- 'http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest' | awk -F\| '/CN\|ipv4/ { printf("%s/%d\n", $4, 32-log($5)/log(2)) }' > chnroute.txt @goodbest chrome/firefox中使用PAC是可以远程DNS解析,不存在dns污染问题. |
3
plqws OP @goodbest 我本来是用 Proxifier 的,然后 twitter、facebook、youtube 因为 dns 污染根本上不去,在Proxifier 设置让 DNS 解析也走代理还是不行,最后换成浏览器代理后就可以了……好像是 Chrome 的 DNS 预加载只能靠自身的代理。
|
5
goodbest 2015-08-04 22:10:42 +08:00
|
7
LazyZhu 2015-08-04 22:15:47 +08:00
|
10
Daniel65536 2015-08-05 01:35:03 +08:00
这就是为什么我写Mono_Pac的时候会加入黑白名单功能……
一般来说DNS只影响少量著名域名,用黑名单处理这些著名域名就好,而IP段这个其实有两方面作用,一个是线路优化,用自己拥有的可靠的VPS中转就能有效加速国外访问,另一方面是国外IP上的东西有可能被关键词reset,国内IP不会放这些关键词,所以IP段还能防reset。 把所有的IP段都跑一次isInNet成本太高了,比较好的做法应该是充分利用排序好的信息,跑一次二分查找,找出最接近的IP段然后测试IP是否在IP段里。 |
11
Daniel65536 2015-08-05 02:54:50 +08:00
跑了下测试,用相同的IP数据Mono_Pac生成的pac体积是你的八分之一,性能是你的近千倍……
所以说所有IP段都跑isInNet是一件开销很大很大的事情。 |
12
digimoon 2015-08-05 07:38:39 +08:00
透明代理还是最舒服
不少程序根本就不理pac这东西,还有那些完全不支持pac的系统例如游戏机 而在pc上面翻的手段和方法太多增删漏缺也更方便 |
13
plqws OP @Daniel65536 嗯,的确昨晚的试用中,有时候打开网页会出现卡在走PAC的阶段,所以性能的确是个大问题。我用 Proxifier 时,相同的 ip 库,相同的做法,相同的排序,性能却比 PAC 不知道高到那里去,而且还能全局代理。做这个的目的只是为了能够访问 twitter、youtube、facebook 这些 DNS 被重点关照的网站,不过最后还是本末倒置了。看来得找一些方法让 Chrome 的 DNS 解析完全走国外代理,其他的交给 Proxifier,感觉这样子才能得到最好的体验。
|