虽然自动判断无法连接的网址很好用，但每次等几秒才去点黄色然后添加。
我比较懒，真诚希望开发者可以给予更懒的使用者开发出更懒的自动模式。
然后自动模式不可访问时可以提示：貌似添加网址后不可访问，是否需要你检查此问题？然后提示是否撒消或继续刚刚的自动设置的网址的问题。
这样就简单多了，或者有时候可以自动判断一两级域名是否含有 Google 字眼，则自动加入自动添加模式。
SwitchyOmega 2.3.15
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36
wclebb
All 6 comments
自动将未加载的资源添加到规则，如果能做得好还是不错的。不过这个技术上比较难，而且作为一个代理设置软件来说，不太希望花太多精力在这上面。
请先尝试一下COW项目，看看是否能达到您的要求。技术上而言，这个项目比 SwitchyOmega 的检测更进一步，是在代理协议级别的检测，应该会更好一些。
FelisCatus
on 3 Aug 2015
这个还是决定不做了。技术上很困难，而且偏离了此项目目标。我还是认为代理软件来做这些事情比较妥当。
当然如果做成插件的形式，由其他有精力的开发人员主导和维护，我是不反对的。插件 API 还在筹划中，见 #44.
FelisCatus
on 20 Apr 2016
额，没想到你还在记住这件事啊……非常惊讶也很感谢。
同时，能否直接判断一个域名下，无论域名下网站是否有其它域名一律翻墙。
不知道是否可以做到？
不过……有个软件 Surge for Mac 软件已经可以做到几乎完美的体验。
根据它的配置文件解释，它的判断是域名是 CN 则走国内（我也不知道怎么做到的），其它域名全走国外。但有一个 Apple 网站域名判断失误，走国内……
相当于把 CN 为白名单，不在白名单一律走翻墙。
我认为如果你还要坚持做下去。
可以不妨做好白名单这件事，即，以某种方式（我也不知道的方法，比如使用了 HICHINA 解析域名或只在国内解析的域名的方式）记录为白名单，并设置为网站一律不翻墙。
不在白名单的，或记录下主流翻墙网站，然后一律走翻墙。
而且我觉得你既然能判断「无法连接的链接」，为什么不能设置为「无法连接的链接试着用翻墙方式代理」，然后「如果用了翻墙方式仍然不行的，告知用户翻墙不成功」。
当然设置需要由用户来设置，根据网络的情况交由用户去设置。不过也觉得没有必要继续了……
wclebb
on 28 Apr 2016
SO 的代理切换是通过事先生成一个 PAC 脚本来实现的。生成时会将规则转换为代码使用，之后 Chrome 自动按照脚本来选择代理， SO 没有干预的余地。根据网页本身的URL来决定资源的URL是做不到的，因为PAC脚本对于所有请求一视同仁，“属于哪个页面的资源”这个信息不可获取。
「无法连接的链接试着用翻墙方式代理」，然后「如果用了翻墙方式仍然不行的，告知用户翻墙不成功」也是做不到的，因为 SO 不发送或者截获请求，当然也没有办法重试或者在指定代理的情况下重试。
同样的道理， SO 也没有办法只从 URL 层面判断请求属于“国内”或者“国外”，判断归属地和路由那是 DNS 和 VPN 应该做的事情。
所以我才说可能距离 SO 作为配置软件的目标差距很大，技术上可行性也很低。之前也说了， COW 项目之类的工作在代理协议层面的东西会更适合这类工作。如果 SO 的目标是解决这类问题，那么当初 SO 就应该选择桌面应用/代理软件等形式，而不是扩展。我知道扩展有很多局限性，不过完成目前的目标是足够了。
最后， SwitchyOmega 不是翻墙软件。我们不提供一站式的解决方案，而是在现有技术情况下提供最灵活的功能，用户可以通过手动/半自动配置的方式来“搭建积木”从而解决用户自身的问题。 SO 只会做代理设置的环节。一个更复杂的解决方案可能包括 SO 作为其一部分，或者如果 SO 没有用就不使用。 Surge 之类的项目针对某些场景特化的功能和设计自然在某些场景是有很大优势的，对此我是持欢迎态度。只不过 SO 没有准备做到那么复杂，也没有准备跨出“代理设置”和“浏览器扩展”的界限。
FelisCatus
on 29 Apr 2016
@wclebb
相当于把 CN 为白名单，不在白名单一律走翻墙。
除了一般使用的黑名单，还有几乎不出神马“未加载的资源”的、现在只适用于 socks5:1080 的白名单 https://github.com/MatcherAny/whitelist.pac
AnyWAT
on 6 Dec 2018
@AnyWAT 友情提示：您回复了一个两年前的贴子。这个贴子的讨论基本上已经结束了，原本的参与者也很可能不再关心相关的更新了。此外，本项目仅讨论 SwitchyOmega 项目本身的问题，我并不推荐在此讨论好用的 PAC 、规则列表、代理服务器之类的问题。
FelisCatus
on 6 Dec 2018
Related issues
FelisCatus
·
4Comments
norci
·
3Comments
paspep
·
3Comments
freb
·
3Comments
zwdzwdzwd
·
3Comments
Most helpful comment
SO 的代理切换是通过事先生成一个 PAC 脚本来实现的。生成时会将规则转换为代码使用，之后 Chrome 自动按照脚本来选择代理， SO 没有干预的余地。根据网页本身的URL来决定资源的URL是做不到的，因为PAC脚本对于所有请求一视同仁，“属于哪个页面的资源”这个信息不可获取。
「无法连接的链接试着用翻墙方式代理」，然后「如果用了翻墙方式仍然不行的，告知用户翻墙不成功」也是做不到的，因为 SO 不发送或者截获请求，当然也没有办法重试或者在指定代理的情况下重试。
同样的道理， SO 也没有办法只从 URL 层面判断请求属于“国内”或者“国外”，判断归属地和路由那是 DNS 和 VPN 应该做的事情。
所以我才说可能距离 SO 作为配置软件的目标差距很大，技术上可行性也很低。之前也说了， COW 项目之类的工作在代理协议层面的东西会更适合这类工作。如果 SO 的目标是解决这类问题，那么当初 SO 就应该选择桌面应用/代理软件等形式，而不是扩展。我知道扩展有很多局限性，不过完成目前的目标是足够了。
最后， SwitchyOmega 不是翻墙软件。我们不提供一站式的解决方案，而是在现有技术情况下提供最灵活的功能，用户可以通过手动/半自动配置的方式来“搭建积木”从而解决用户自身的问题。 SO 只会做代理设置的环节。一个更复杂的解决方案可能包括 SO 作为其一部分，或者如果 SO 没有用就不使用。 Surge 之类的项目针对某些场景特化的功能和设计自然在某些场景是有很大优势的，对此我是持欢迎态度。只不过 SO 没有准备做到那么复杂，也没有准备跨出“代理设置”和“浏览器扩展”的界限。