这是一个创建于 4201 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚发现PandaFan的服务在Wi-Fi下出现了故障，3G下则没有问题，仔细排查了一下发现问题只可能出在PAC脚本上。
PandaFan的PAC是白名单机制，即：记录在PAC的白名单list中的域名会直接连接，未在白名单中找到的域名和直接的IP访问会通过代理来访问。
白名单是会自动学习的，详见： http://v2ex.com/t/64373
首先尝试打开Tweetbot for Mac，发现无法刷出TL新内容，虽然下拉出现的更新条出显示的是Streaming...
查看 chrome://net-internals/#proxy 发现应用PAC的情况下，Effective settings居然是direct connection。检查了下当前的白名单域名数，发现已经增长到了9000多个，猜测是否是域名太多了超出浏览器限制，于是就把之前一份只有5000多域名的白名单备份替换了上去，问题解决了，浏览器重新应用了PAC脚本，Tweetbot等应用，包括系统的通知中心也重新开始正常工作。
这个问题具体产生的原因还是不清楚，但可以排除是PAC文件过大的原因（9000多域名的PAC文件大小为131KB）
另外，PandaFan的PAC执行的具体流程是：
先将访问的域名和一份很短的黑名单进行匹配，如果匹配成功会直接通过代理访问，没有在黑名单离匹配到的才会再进行白名单匹配。
这样的设计能解决一个问题：当自动学习生成的白名单中收录有无法访问的域名时，只要黑名单中收录有该域名，那么就能正确的通过代理去访问。
而现在发现的情况是系统根本没有去应用这个PAC，直接统统进行了直接访问，非常奇怪
大家有什么猜想吗？
或者有哪位老师了解的比较多，可以分享一下背后的原理？
PandaFan的PAC是白名单机制，即：记录在PAC的白名单list中的域名会直接连接，未在白名单中找到的域名和直接的IP访问会通过代理来访问。
白名单是会自动学习的，详见： http://v2ex.com/t/64373
首先尝试打开Tweetbot for Mac，发现无法刷出TL新内容，虽然下拉出现的更新条出显示的是Streaming...
查看 chrome://net-internals/#proxy 发现应用PAC的情况下，Effective settings居然是direct connection。检查了下当前的白名单域名数，发现已经增长到了9000多个，猜测是否是域名太多了超出浏览器限制，于是就把之前一份只有5000多域名的白名单备份替换了上去，问题解决了，浏览器重新应用了PAC脚本，Tweetbot等应用，包括系统的通知中心也重新开始正常工作。
这个问题具体产生的原因还是不清楚，但可以排除是PAC文件过大的原因（9000多域名的PAC文件大小为131KB）
另外，PandaFan的PAC执行的具体流程是：
先将访问的域名和一份很短的黑名单进行匹配，如果匹配成功会直接通过代理访问，没有在黑名单离匹配到的才会再进行白名单匹配。
这样的设计能解决一个问题：当自动学习生成的白名单中收录有无法访问的域名时，只要黑名单中收录有该域名，那么就能正确的通过代理去访问。
而现在发现的情况是系统根本没有去应用这个PAC，直接统统进行了直接访问，非常奇怪
大家有什么猜想吗？
或者有哪位老师了解的比较多，可以分享一下背后的原理？
 |
1
XiegongJi 2013-05-26 21:32:10 +08:00  1
貌似某些浏览器对PAC脚本中的数组元素个数有限制。
不过你可以多定义几个数组或对同一数组多次赋值，从而突破这个限制: auto_list=[a,b,c];//元素个数不要超过MAX_SIZE //some code ... auto_list=[d,e,f];//元素个数不要超过MAX_SIZE //some code ... auto_list=[g,h,i];//元素个数不要超过MAX_SIZE //some code ... |
Select Language