希望重新加回PAC模式

[QingyuQingxue]

preview版本已经移除了PAC模式 希望后续版本能重新添加

[Molarczsq]

I agree！！！！ 我同意，太难受了

[xiaoyaoyuxin]

习惯用pac。

这是要学习Q2ray吗?

[simpleandstupid]

pac相对于core的路由没有任何优势，这已经是上古时代的产物了。同样是2dust的作品ng没有pac也没见出什么问题。 （本来也就n还留着pac）

[yfdyh000]

pac相对于core的路由没有任何优势，这已经是上古时代的产物了。同样是2dust的作品ng没有pac也没见出什么问题。 （本来也就n还留着pac）

路由不支持网址级。

[yfdyh000]

pac相对于core的路由没有任何优势，这已经是上古时代的产物了。同样是2dust的作品ng没有pac也没见出什么问题。 （本来也就n还留着pac）

路由不支持网址级。

domain:www.XXX.com 我猜你说的是这种？

比如特定域名https/http区别对待，特定路径、网址的区别对待、黑/白名单。 虽然gfwlist年久失修，但"路由规则"个人感觉不怎么透明和易懂。

[mclovin-2k]

pac相对于core的路由没有任何优势，这已经是上古时代的产物了。同样是2dust的作品ng没有pac也没见出什么问题。 （本来也就n还留着pac）

路由不支持网址级。

domain:www.XXX.com 我猜你说的是这种？

比如特定域名https/http区别对待，特定路径、网址的区别对待、黑/白名单。 虽然gfwlist年久失修，但"路由规则"个人感觉不怎么透明和易懂。

你说的这些 Routing 都可以很简单实现。

[l4326769]

新版本我也用了，没有pac有一些不习惯，首先说一下pac吧，pac只有出现在规则里面的方可进入国内外分流判断，其他一律走直连，这与全局模式不同的是，全局模式会把所有的流量都进入国内外分流判断,对于我来说因为需要记录流量日志，更少的流量日志反而能减轻我的工作量。另一点和自带路由功能不同的就是pac是依据pac.txt来管理的，自带路由功能则是和节点信息整合在一起的，然而这一点我也踩过雷，乱改节点信息把节点文件弄坏了，不得已才删除节点文件，单独的文件管理我认为会更好一点。我还是希望把PAC模式以及绕行规则加回来

[l4326769]

而且，对于我个人而言，需要代理的域名很少很少，其他的海外网站都走直连，全局模式依然要把这些不需要代理的域名再一次设置，有时候可能DNS有点问题导致流量偷跑，我觉得pac模式还是有必要加进来的

[l4326769]

新版本我也用了，没有pac有一些不习惯，首先说一下pac吧，pac只有出现在规则里面的方可进入国内外分流判断，其他一律走直连，这与全局模式不同的是，全局模式会把所有的流量都进入国内外分流判断,对于我来说因为需要记录流量日志，更少的流量日志反而能减轻我的工作量。另一点和自带路由功能不同的就是pac是依据pac.txt来管理的，自带路由功能则是和节点信息整合在一起的，然而这一点我也踩过雷，乱改节点信息把节点文件弄坏了，不得已才删除节点文件，单独的文件管理我认为会更好一点。我还是希望把PAC模式以及绕行规则加回来

请问是clash用户吗，请理解一下路由功能和节点是分离的，clash是强行把乱七八糟的功能都绑定在一起， #1200 (comment) 我在这里也提了，希望重复造轮子，做一个导入导出路由配置的选项

日志应该是无解的，不过如果真是做日志分析的，安卓的日志一秒几万条，开发安卓的人照样在继续开发，你只需要筛选出有用的信息即可

我是说流量日志，对于pac来说没有出现在规则里的流量不会进入代理端口，当然也不会记录日志，我通常需要这些日志来判断规则是否完整，如果全局的话，一些无关流量都被记录在日志上，反而会加重我的工作量。

[l4326769]

新版本我也用了，没有pac有一些不习惯，首先说一下pac吧，pac只有出现在规则里面的方可进入国内外分流判断，其他一律走直连，这与全局模式不同的是，全局模式会把所有的流量都进入国内外分流判断,对于我来说因为需要记录流量日志，更少的流量日志反而能减轻我的工作量。另一点和自带路由功能不同的就是pac是依据pac.txt来管理的，自带路由功能则是和节点信息整合在一起的，然而这一点我也踩过雷，乱改节点信息把节点文件弄坏了，不得已才删除节点文件，单独的文件管理我认为会更好一点。我还是希望把PAC模式以及绕行规则加回来

请问是clash用户吗，请理解一下路由功能和节点是分离的，clash是强行把乱七八糟的功能都绑定在一起， #1200 (comment) 我在这里也提了，希望重复造轮子，做一个导入导出路由配置的选项

日志应该是无解的，不过如果真是做日志分析的，安卓的日志一秒几万条，开发安卓的人照样在继续开发，你只需要筛选出有用的信息即可

省一楼，direct规则留空，填写一行proxy规则 geosite:gfw 即可回归传统PAC模式

上面我也说了，对于我个人而言，需要代理的域名很少很少，仅仅是国外比较有名的网站，也就五六个，其他的连上又会触发审计，看到触发审计信息就有点不舒服，反正萝卜青菜各有所爱吧，自己觉得好用的不一定别人就觉得好用

[KC9226]

没有PAC，照样好使。geosite,geoip非常好用，且非常新。

[CatSamaDD]

同支持加回PAC，很不解，楼上有些人觉得梨好吃，但为什么要把别人的苹果拿走呢？

[horace-wu]

PAC 是上古时代的产物？历史悠久也是罪？

PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。
路由相当于身家性命全部交付给翻墙软件，过程不透明。

PAC 更简洁。我们常见的需要翻墙的域名本来就不多。
Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

[l4326769]

PAC 是上古时代的产物？历史悠久也是罪？ PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。 路由相当于身家性命全部交付给翻墙软件，过程不透明。 PAC 更简洁。我们常见的需要翻墙的域名本来就不多。 Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

我也说了，PAC并没有被砍，因为PAC根本不属于v2ray，你完全可以自己把自己的PAC文件放入相应的软件里即可运行，windows就在代理界面填入即可 剔除不属于v2ray的东西，专注于v2ray，保持项目的完整我觉得没啥不对的，v2ray提供了优于ss的路由功能，为什么不善加利用，自己家里金山银山，却看着PAC家里的破铜烂铁眼馋，我是真的不懂 每一个创新如果都能被"不会用"压下来，那我就不知道你们为什么在用v2ray和trojan了，ss明明也能作为翻墙用途

况且，提升用户使用门槛到底是好事还是坏事，懂得都懂

可以告诉我文件格式，以及详细设置吗，我式好几次都失败了

[horace-wu]

PAC 是上古时代的产物？历史悠久也是罪？ PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。 路由相当于身家性命全部交付给翻墙软件，过程不透明。 PAC 更简洁。我们常见的需要翻墙的域名本来就不多。 Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

我也说了，PAC并没有被砍，因为PAC根本不属于v2ray，你完全可以自己把自己的PAC文件放入相应的软件里即可运行，windows就在代理界面填入即可 剔除不属于v2ray的东西，专注于v2ray，保持项目的完整我觉得没啥不对的，v2ray提供了优于ss的路由功能，为什么不善加利用，自己家里金山银山，却看着PAC家里的破铜烂铁眼馋，我是真的不懂 每一个创新如果都能被"不会用"压下来，那我就不知道你们为什么在用v2ray和trojan了，ss明明也能作为翻墙用途

况且，提升用户使用门槛到底是好事还是坏事，懂得都懂

好吧，PAC 没有被砍，是在下看错了。 即使砍掉 PAC 也是因为 PAC 差，PAC 上古，用 PAC 的人有问题，也听懂了。

不过我还是觉得 系统 PAC 更安全更透明更简单，不想把所有请求交给翻墙软件。

[horace-wu]

PAC 是上古时代的产物？历史悠久也是罪？ PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。 路由相当于身家性命全部交付给翻墙软件，过程不透明。 PAC 更简洁。我们常见的需要翻墙的域名本来就不多。 Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

我也说了，PAC并没有被砍，因为PAC根本不属于v2ray，你完全可以自己把自己的PAC文件放入相应的软件里即可运行，windows就在代理界面填入即可 剔除不属于v2ray的东西，专注于v2ray，保持项目的完整我觉得没啥不对的，v2ray提供了优于ss的路由功能，为什么不善加利用，自己家里金山银山，却看着PAC家里的破铜烂铁眼馋，我是真的不懂 每一个创新如果都能被"不会用"压下来，那我就不知道你们为什么在用v2ray和trojan了，ss明明也能作为翻墙用途 况且，提升用户使用门槛到底是好事还是坏事，懂得都懂

好吧，PAC 没有被砍，是在下看错了。 即使砍掉 PAC 也是因为 PAC 差，PAC 上古，用 PAC 的人有问题，也听懂了。 不过我还是觉得 系统 PAC 更安全更透明更简单，不想把所有请求交给翻墙软件。

懂，应该交给闭源的chrome和windows来处理请求，不能交给开源的v2ray-core，我完全明白

不信任 Chrome,Windows 这些就说笑了。 这个跟开源无关，也不是对 v2ray-core 的不信任，不信任就根本不会用呀，不信任的只是机场而已。有时候可能是一个失误或者配置错误各种不可控的后果都有可能，不能否认 PAC 是系统规则透明安全可控，可以比较清楚的配置有限的国外网站与翻墙软件发生关系。

[horace-wu]

PAC 是上古时代的产物？历史悠久也是罪？ PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。 路由相当于身家性命全部交付给翻墙软件，过程不透明。 PAC 更简洁。我们常见的需要翻墙的域名本来就不多。 Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

我也说了，PAC并没有被砍，因为PAC根本不属于v2ray，你完全可以自己把自己的PAC文件放入相应的软件里即可运行，windows就在代理界面填入即可 剔除不属于v2ray的东西，专注于v2ray，保持项目的完整我觉得没啥不对的，v2ray提供了优于ss的路由功能，为什么不善加利用，自己家里金山银山，却看着PAC家里的破铜烂铁眼馋，我是真的不懂 每一个创新如果都能被"不会用"压下来，那我就不知道你们为什么在用v2ray和trojan了，ss明明也能作为翻墙用途 况且，提升用户使用门槛到底是好事还是坏事，懂得都懂

好吧，PAC 没有被砍，是在下看错了。 即使砍掉 PAC 也是因为 PAC 差，PAC 上古，用 PAC 的人有问题，也听懂了。 不过我还是觉得 系统 PAC 更安全更透明更简单，不想把所有请求交给翻墙软件。

懂，应该交给闭源的chrome和windows来处理请求，不能交给开源的v2ray-core，我完全明白

不信任 Chrome,Windows 这些就说笑了。 这个跟开源无关，也不是对 v2ray-core 的不信任，不信任就根本不会用呀，不信任的只是机场而已。有时候可能是一个失误或者配置错误各种不可控的后果都有可能，不能否认 PAC 是系统规则透明安全可控，可以比较清楚的配置有限的国外网站与翻墙软件发生关系。

小知识：PAC与v2ray-core是不交互的，v2ray-core意识不到PAC的存在，就和透明代理一样，PAC是上级，上级消化完了才给下级的v2ray-core代理 小知识2：PAC解析的过程日志在解析的软件上，使你误以为对那些过滤的网站根本没有产生日志，所以感到了透明安全 小知识3：路由可以设置为PAC模式，也就是黑名单模式，与PAC在功能上无异，甚至有额外功能实现各种骚操作 小知识4：躲避机场审查的方法有一个，OpenVPN over v2ray 即可，这样机场只能看到你的IP和你的服务器IP，而不会知道你请求的网址IP

抱歉你的小知识是错误的， PAC是由系统提供的脚本规则且透明可控，无论是PAC脚本还是浏览器都不会出现你所说的安全问题。 也正是因为PAC完全独立，不与翻墙软件发生关系，所以安全可控。

你说的路由可以替代 PAC 的黑名单模式，这个任何人都知道，但是你的前提请要请求翻墙软件，所有的请求都被翻墙软件控制，抱歉至少我是做不到。

你觉得好那你用吧，反正我不用，不多说了。

[horace-wu]

PAC 是上古时代的产物？历史悠久也是罪？ PAC 是系统提供的代理规则，过程透明可控，本身我们就只要少数外国网站经过翻墙软件即可。 路由相当于身家性命全部交付给翻墙软件，过程不透明。 PAC 更简洁。我们常见的需要翻墙的域名本来就不多。 Telegram 的这种特殊例子根本不足以作为放弃 PAC 的理由，直接到 Telegram 里指定一下代理端口本来就很简单，如果这么简单的事都不会操作，不能指望他可以使用更复杂的IP路由配置。

我也说了，PAC并没有被砍，因为PAC根本不属于v2ray，你完全可以自己把自己的PAC文件放入相应的软件里即可运行，windows就在代理界面填入即可 剔除不属于v2ray的东西，专注于v2ray，保持项目的完整我觉得没啥不对的，v2ray提供了优于ss的路由功能，为什么不善加利用，自己家里金山银山，却看着PAC家里的破铜烂铁眼馋，我是真的不懂 每一个创新如果都能被"不会用"压下来，那我就不知道你们为什么在用v2ray和trojan了，ss明明也能作为翻墙用途 况且，提升用户使用门槛到底是好事还是坏事，懂得都懂

好吧，PAC 没有被砍，是在下看错了。 即使砍掉 PAC 也是因为 PAC 差，PAC 上古，用 PAC 的人有问题，也听懂了。 不过我还是觉得 系统 PAC 更安全更透明更简单，不想把所有请求交给翻墙软件。

懂，应该交给闭源的chrome和windows来处理请求，不能交给开源的v2ray-core，我完全明白

不信任 Chrome,Windows 这些就说笑了。 这个跟开源无关，也不是对 v2ray-core 的不信任，不信任就根本不会用呀，不信任的只是机场而已。有时候可能是一个失误或者配置错误各种不可控的后果都有可能，不能否认 PAC 是系统规则透明安全可控，可以比较清楚的配置有限的国外网站与翻墙软件发生关系。

小知识：PAC与v2ray-core是不交互的，v2ray-core意识不到PAC的存在，就和透明代理一样，PAC是上级，上级消化完了才给下级的v2ray-core代理 小知识2：PAC解析的过程日志在解析的软件上，使你误以为对那些过滤的网站根本没有产生日志，所以感到了透明安全 小知识3：路由可以设置为PAC模式，也就是黑名单模式，与PAC在功能上无异，甚至有额外功能实现各种骚操作 小知识4：躲避机场审查的方法有一个，OpenVPN over v2ray 即可，这样机场只能看到你的IP和你的服务器IP，而不会知道你请求的网址IP

抱歉你的小知识是错误的， PAC是由系统提供的脚本规则且透明可控，无论是PAC脚本还是浏览器都不会出现你所说的安全问题。 你说的路由可以替代 PAC 的黑名单模式，这个任何人都知道，但是你的前提请要请求翻墙软件，所有的请求都被翻墙软件控制，抱歉至少我是做不到。 你觉得好那你用吧，反正我不用，不多说了。

懂，闭源的软件都会遵守PAC的规则，不会把你的请求复制一份发送到他的服务器上，也不会控制你的所有请求，只是过一遍而已，所以也不会给你看日志，而v2ray-core都是先代理直连流量，再直连，所以有日志，我完全明白

又在说 Chrome 会把请求复制一份发到服务器上？ Chrome 是基于开源项目，如果你这么不信任 Chrome 的话，请问你是自己开发浏览器上网吗？

砍PAC就砍PAC，为什么要把PAC踩得一文不值呢，而且用这胡编的理由，那之前支持PAC又是什么，是因为上述的你说用PAC的人怎么的怎么的？！

[horace-wu]

又在说 Chrome 会把请求复制一份发到服务器上？ Chrome 是基于开源项目，如果你这么不信任 Chrome 的话，请问你是自己开发浏览器上网吗？ 砍PAC就砍PAC，为什么要把PAC踩得一文不值呢，而且用这胡编的理由，那之前支持PAC又是什么，是因为上述的你说用PAC的人怎么的怎么的？！

#1199 (comment)

不过我还是觉得 系统 PAC 更安全更透明更简单，不想把所有请求交给翻墙软件。

我无所谓的，我即使浏览记录都在谷歌服务器上我也懒得去管，我只是想说 把所有请求交给闭源软件比交给翻墙软件安全 这个观点是错的

哦，你的意思是 翻墙软件 + 机场 比 Google 出的 Chrome 安全啊，好吧我也无所谓的。 那我还是用透明安全可控的PAC吧，反正你也说了 PAC 跟 v2ray-core 没有关系，我们有使用 PAC 的自由，至于有人说用了 PAC 就怎么样怎么样，倒也无所谓，反正 V2rayN 至少是曾经用过。

[horace-wu]

can you read chinese? wtf is 机场, i didn't say anything about 机场, i only said giving all the requests to a closed-source software is not safer than to an open-source one.

翻墙软件会直接与机场打交道， 路由配置错误或者各种不可控的原因会导致请求被人为或故意转发到机场的可能。

所以我宁愿使用PAC控制有限的国外域名与翻墙软件发生关系。 因为如你所述，PAC与机场没有一毛钱的关系，至于你一直在暗示 Google Chrome 不可信 - 很没有水平，也非常无趣，你用路由没有 Google 活动记录？！你不知道这个只有自己可以看到？！或者你不知道这个是可以关闭的？！

总之你说的都对随你好了，我还是决定继续用 PAC

[horace-wu]

即然愿意用 PAC 的还有很多，请你不要在网络上攻击一个群体， 我只是合理分析了一下 PAC 不与翻墙软件发生关系，就扯到别人的人品有问题。 例如你在公司，可能不让你带U盘复制代码回家，就是你老板的人品有问题，不信任你？ 这是什么讨论习惯？

[horace-wu]

说得自己跟神一样，能预测到你的路由一百年后都是安全的，永远不会发生问题，还有很多翻墙软件作者直接消失了，项目和自动更新最后被谁控制都不知道，我们当然要提前预防，谈信任还用什么翻墙软件匿什么名。

[horace-wu]

路由配置错误或者各种不可控的原因会导致请求被人为或故意转发到机场的可能。

是，PAC配置错误也不会发生这个情况！

至于你一直在暗示 Google Chrome 不可信 - 很没有水平，也非常无趣，你用路由没有 Google 活动记录？！你不知道这个只有自己可以看到？！或者你不知道这个是可以关闭的？！

是，谷歌虽然有这个技术，但是还是提供给你关闭的选项的，根本不可能存在你关闭后仍然在获取你的记录的情况！

就扯到别人的人品有问题。

是，我的回复里包含 人品有问题 的关键字了！

说得自己跟神一样，能预测到你的路由一百年后都是安全的，永远不会发生问题，还有很多翻墙软件作者直接消失了，项目和自动更新最后被谁控制都不知道，我们当然要提前预防，谈信任还用什么翻墙软件匿什么名。

是，开源的软件即使是自己review了一遍代码并自己编译了，但是还是有后门的！我们当然要提前预防开源的路由功能带来的问题！而我们的PAC则是完美无瑕的！PAC虽然运行在闭源的软件内，但是是永远安全的！

嗯嗯， PAC脚本简洁，所以不容易出问题， PAC可以只配置代理域名，默认直连，所以基本不会出错。 PAC与翻墙软件没有关系，不会又做裁判又做运动员。 PAC运行在闭源软件内？你在说笑话吧？！Windows系统代理并不会运行PAC ! 操作系统也不可信任，浏览器也不可信任，你都是自己写操作系统运行自己写的浏览器上网是吧？！

至于其他的对我的话的歪曲，例如我没有说过路由不能配置域名和IP，我就不解释了。 看得出你与任何人争论是必赢的，好吧你赢了，你肯定赢了，即然赢得那么自信，不用再打这么多字了，睡觉去了。

[horace-wu]

不逗你了，路由做默认直连是秒秒钟的事情，请你先了解下在评判路由，我刚才去试了下，debug状态下(即记录所有的日志)，直连的记录在服务端是看不到的，所以路由功能是纯属本地实现的，不是看到了直连日志就认为是服务端获取了你的直连记录

一直在歪曲别人的话，我也是服了， 我从来没有说过路由不能这个不能那个，我说的是路由由翻墙软件控制，从来没见过像你这么固执的，生活中应当经常与人发生争吵吧。

[horace-wu]

还特别强调一下一晚上是在逗别人，跟个小孩似的。

[horace-wu]

看了一下你自己的签名就是 ”暴躁老哥“，真担心你迟早会把自己气死，上半句没看完就直接把别人的话歪曲出下半句了。

[horace-wu]

不逗你了，路由做默认直连是秒秒钟的事情，请你先了解下在评判路由，我刚才去试了下，debug状态下(即记录所有的日志)，直连的记录在服务端是看不到的，所以路由功能是纯属本地实现的，不是看到了直连日志就认为是服务端获取了你的直连记录

一直在歪曲别人的话，我也是服了， 我从来没有说过路由不能这个不能那个，我说的是路由由翻墙软件控制，从来没见过像你这么固执的，生活中应当经常与人发生争吵吧。

#1199 (comment)

这个跟开源无关，也不是对 v2ray-core 的不信任，不信任就根本不会用呀，不信任的只是机场而已。有时候可能是一个失误或者配置错误各种不可控的后果都有可能，不能否认 PAC 是系统规则透明安全可控，可以比较清楚的配置有限的国外网站与翻墙软件发生关系。

我语文真的不好，如果你开头就说清楚了，我就理解了，我还以为你说的是机场呢，原来不信任的是v2ray-core

又开始扣帽子了，我说的是 v2ray-core 会直接与机场打交道，医生护士戴口罩就等于不信任医生护士？！ 你是不是少根弦？你这么乱歪曲别人的话能让你得一百分三好学生？

不想再理你了。

[1265578519]

pac来说速度更快效果更好，全局模式的话，所有流量要经过v2ray核心，会占用大量的CPU引起卡顿，PAC可以科学有效的降低CPU负载，因为PAC可以在进入v2ray核心之前，windows系统底层内核就把流量划分掉了 如果用全局模式，包括迅雷下载，等等任何软件，都要经过v2ray核心，严重拖慢了网速，增加CPU开销浪费资源，并且v2极限吞吐量也就在200M左右，，如果1000M宽带用全局模式，会变成200M宽带 这种模式在电脑上用意义不大，所以PAC分流更加适合 而且，gfwlist项目也在正常维护中，并没有停更 https://github.com/gfwlist/gfwlist/commits/master

所以，删除PAC功能是没有意义的，如果不进行维护开发PAC这个功能，没必要删除，可以作为一个设置可选功能让用户进行开启，而不是整个删除，你说用旧版？那旧版就体验不到新版的其它功能和BUG修复了，这点不太可取啊

[1265578519]

@SekiBetu 如果能做到性能无损耗，那么大家肯定都是满意的了，主要是这一点，PAC的优势也是如我上面说的因为PAC可以在进入v2ray核心之前，windows系统底层内核就把流量划分掉了，而不是你说所的启用PAC过程通过JavaScript解析网址域名网址产生的性能消耗

例如openvpn也是这种原理也是非常棒的，通过路由表的手段，在进入v2ray-core之前，就划分掉流量， 你们现在的做法却是，，，让所有流量进入core，然后进行划分？这点就很不科学了，对于你说的分流多台服务器TCP UDP等流量，99%的大部分人都没有这种需求，基本就是刷刷浏览器网页，这开发的路由新模式做法纯粹就是浪费让CPU消耗做没意义的事情 因为core本身go代码是单线程运行的，只能吃一个核心利用CPU执行效率很垃圾，就会引起上面我所说的流量吞吐量问题，如果你们开发都能解决这问题，各位相信都很乐意尝试代替PAC的新模式

最简单的测试手段，现在新模式，打开IDM等支持代理的下载软件，然后新模式中路由划掉流量，让其不经过vps服务器，直接在本地处理路由旁路，进行大流量下载，然后观察v2ray-core核心cpu占用情况 或者测试chrome大流量下载一个文件包之类，也可以进行观察占用率 PAC模式可以让其做到0%的占用率稳定运行不浪费任何的性能损耗，因为流量根本就不会通过core

所以，你们开发新功能新玩法可以，，，不要把老的已经实现稳定运行功能给砍掉，这样大家也没意见

顺便，，PAC是系统底层的，只要是软件拉起系统代理功能的都能支持，除非软件中内置了一套另外的代理功能才不会被支持，典型的软件，例如你说的tg，软件中内置了一套额外的代理功能

[l4326769]

使用PAC必须要肩负起解决与各种其他软件之间的冲突问题，这已经不是一个GUI软件的能力范围之内了，不翻不知道，WIN10目前为止仍然与PAC有冲突，线程大量积压的问题仍未解决

大家更应该把时间用在刀刃上，而不是去解决这些PAC的无意义问题，写一堆屎代码去兼容PAC 切换成路由模式，让v2ray解放自己的双手，把时间放在开发新东西上，这才是对用户而言最大的好事

能尊重一下写代码的人好吗，冲突归冲突，软件不走pac，全局代理也不会走，pac和路由模式可以同时存在，为了提升路由模式的分流性，而去砍掉代理模式，你觉得开心了不代表别人也感到开心

[l4326769]

你用过吗，会用pac的基本上不会切换全局模式好吗，自己不愿意编辑怪代理模式

[l4326769]

自带的pac更新功能从哪里更新的都不知道，代理了什么网站自然也会有问题，然而却把这种问题嫁祸于代理模式

[l4326769]

我喜欢用pac，我自己动手编辑怎么了，就因为很多人不知道怎么编辑，还在使用自带的更新pac的功能，才导致了网站上不去各种问题，然后他们说是模式的问题，实则是名单问题，然后就一下把功能砍掉了，确实有所不妥

[l4326769]

我喜欢用pac，我自己动手编辑怎么了，就因为很多人不知道怎么编辑，还在使用自带的更新pac的功能，才导致了网站上不去各种问题，然后他们说是模式的问题，实则是名单问题，然后就一下把功能砍掉了，确实有所不妥

使用4.1版本的默认路由设置，可以让这一大批不会的人无脑使用且不需要频繁切换，这不妥嘛，非要你来指导一个一个教他们写PAC？

不好意思，我还真教过

[l4326769]

我喜欢用pac，我自己动手编辑怎么了，就因为很多人不知道怎么编辑，还在使用自带的更新pac的功能，才导致了网站上不去各种问题，然后他们说是模式的问题，实则是名单问题，然后就一下把功能砍掉了，确实有所不妥

使用4.1版本的默认路由设置，可以让这一大批不会的人无脑使用且不需要频繁切换，这不妥嘛，非要你来指导一个一个教他们写PAC？

不好意思，我还真教过

如果就因为不会编辑就砍掉，便利一部分人却又不便利了另一部分人，只能说作者考虑的不全面

[xiaoksks]

Qv2ray的路由编辑器真的十分好用吗？！

iyideng站长：winXray在使用体验上秒杀Qv2ray，如果你使用过winXray客户端的话，那种柔顺丝滑的感觉会让你再也不想用Qv2ray了，因为Qv2ray真是太难用了。

试了下，还不戳，不过订阅服务之后，服务器数量不对，安卓版本不知道有没有安排

[xiaoksks]

请PAC用户务必使用这个winXray，他支持PAC，害，问题终于圆满解决了，winXray的诞生真是及时雨，终于没必要把这PAC加回来了

现在这个新版本，就是访问很多国内网站直接就挂了，需要手动加到direct里面去，或者把代理关了，有什么其他好的办法吗？频繁做这种操作很恶心啊，对于上网比较重度的人的话

[l4326769]

请PAC用户务必使用这个winXray，他支持PAC，害，问题终于圆满解决了，winXray的诞生真是及时雨，终于没必要把这PAC加回来了

现在这个新版本，就是访问很多国内网站直接就挂了，需要手动加到direct里面去，或者把代理关了，有什么其他好的办法吗？频繁做这种操作很恶心啊，对于上网比较重度的人的话

用3.29包括3.29以前的版本，新版本啥都给你走代理，小众网站需要自己添加直连

[l4326769]

请PAC用户务必使用这个winXray，他支持PAC，害，问题终于圆满解决了，winXray的诞生真是及时雨，终于没必要把这PAC加回来了

现在这个新版本，就是访问很多国内网站直接就挂了，需要手动加到direct里面去，或者把代理关了，有什么其他好的办法吗？频繁做这种操作很恶心啊，对于上网比较重度的人的话

用3.29包括3.29以前的版本，新版本啥都给你走代理，小众网站需要自己添加直连

请使用winXray

没必要改变自己的使用习惯，winXray使用起来还是很难受的

[l4326769]

请PAC用户务必使用这个winXray，他支持PAC，害，问题终于圆满解决了，winXray的诞生真是及时雨，终于没必要把这PAC加回来了

现在这个新版本，就是访问很多国内网站直接就挂了，需要手动加到direct里面去，或者把代理关了，有什么其他好的办法吗？频繁做这种操作很恶心啊，对于上网比较重度的人的话

用3.29包括3.29以前的版本，新版本啥都给你走代理，小众网站需要自己添加直连

请使用winXray

你喜欢路由模式你就喜欢呗，你要赶走人不让用v2rayN是想怎样

[horace-wu]

仔细看了下 V2rayN，v2ray-Core 贡献者里都没有 SekiBetu，而且对 V2rayN 的代码、V2rayN 的其他用户都口吐芬芳。想一想真可怕，如果让这样的人执政，只怕墙会厚一百倍。

[l4326769]

仔细看了下 V2rayN，v2ray-Core 贡献者里都没有 SekiBetu，而且对 V2rayN 的代码、V2rayN 的其他用户都口吐芬芳。想一想真可怕，如果让这样的人执政，只怕墙会厚一百倍。

不好意思给你添麻烦了，本人就这个暴脾气，好东西我都是想让大家第一时间用上，好心办坏事了，强扭的瓜不甜

你觉得好不就好，干嘛把自己的观点强加到别人身上

[KGB333]

个人看法觉得现在这个全局+路由规则更强大，也希望大家尊重作者的决定和付出，毕竟还是测试版，想用PAC的大可不升级，也不影响正常使用和性能，或者作者可以考虑在之后change log加入一些指引让未使用过路由规则的用户去进行路由规则设置，感谢每一位大佬的付出

[1265578519]

pac是目前最优秀的代理模式无需质疑 不然Windows也不会默认集成并且支持 微软又不傻 至于gui开发者怎么搞都行，我们大家一起用旧版本就行了

[superbirds2008]

我做了个python脚本，用uwsgi挂载到nginx。需要配置代理的时候，在浏览器/IOS手机的代理-自动配置栏填入在线工具地址加个socks服务器的IP地址作为参数就会返回根据gfwlist更新的pac文件，文件里面的socks地址就是填入的IP地址。需要的话可以分享给大家

[zhj9709]

https://github.com/Loyalsoldier/v2ray-rules-dat

[zhj9709]

可以设置gfwlist代理，其他直连

[Itzamana]

这里的戾气怎么这么大… 开源软件可以提建议，但采纳不采纳是作者说了算，如果作者决意不想支持PAC代理，那自己Fork一下就行了。

[Cp0204]

这里的戾气怎么这么大… 开源软件可以提建议，但采纳不采纳是作者说了算，如果作者决意不想支持PAC代理，那自己Fork一下就行了。

赞同，作者用爱发电，无法满足所有人的需求。

[LiDaiyan]

我喜欢用pac，我自己动手编辑怎么了，就因为很多人不知道怎么编辑，还在使用自带的更新pac的功能，才导致了网站上不去各种问题，然后他们说是模式的问题，实则是名单问题，然后就一下把功能砍掉了，确实有所不妥

使用4.1版本的默认路由设置，可以让这一大批不会的人无脑使用且不需要频繁切换，这不妥嘛，非要你来指导一个一个教他们写PAC？

不好意思，我还真教过

老哥能给份PAC规则表或者网址么，我google了好几页也没看到官方规则说明（可能姿势有问题），主要是我在本地试，有的规则对有的不对，我不知道哪里出了问题。