simplerick-simplefun

> @simplerick-simplefun 感谢大佬~ > > 1. 我一直用的 cloudfare 的域名访问的，A记录配置 xx.com 二级域名指定ip，A记录配置的二级域名从未直接使用过；C记录配置 xx.xx.com 代理 xx.com，v2ray 一直都是访问 xx.xx.com 这个三级域名； > 2. 确实是小米k40 用iPhone的5G热点可以访问，但是比直接连家里的wifi慢； > 3. 此外在 iphone 上的 shadowrocket 客户端做连通性测试是通的，延迟200-300ms 左右正常范围 >...

> 所以结论应该是 我这个域名 被联通强了吧 一般会认为你手机的流量网络墙了这个梯子，但是既然你用红米k40连接iphone的流量热点可以用梯子，就说明不是墙而是其他的因素。这里你可以用红米k40连接iphone的流量热点试一下，应该x1.xx.com xx.com x2.xx.com三个域名都可以在红米k40上打开。 那么我倾向于认为是（基于某种原因）iphone上面的域名解析被污染了，而红米k40没有。 这里你直接在iphone梯子客户端填写ip，不要填写域名，应该就能用了。具体的办法是，用你的电脑cmd ping一下xx.com，或者百度一下dns解析，随便找个国内的服务解析一下你的域名得到ip，应该就能得到CF的中继/代理ip了。然后在服务器地址项填写这个IP（而不是域名），其他不变。 ``` "outbounds": [ { "protocol": "xxxx", "settings": { "vnext": [ { "address": "填写IP", "port": 443, "users": [ ``` 另外你也可以分别在iphone和红米上安装个ping功能的应用，分别ping一下xx.com，我觉得应该会给出不同的ip。

我读了一下代码。我好久没手写代码了，而且也没学过go。具体的细节感觉读的脑壳疼。反正要不就是这个语言缺少可读性，要不就是写得不好读。 关键的逻辑处理在： https://github.com/v2fly/v2ray-core/blob/fc6ae4d4e7f5158d7222a42c749d2bf7ca913632/app/dns/dns.go#L271 其中的Match是这个： https://github.com/v2fly/v2ray-core/blob/fc6ae4d4e7f5158d7222a42c749d2bf7ca913632/common/strmatcher/indexmatcher_linear.go#L42 而确定这个事的则是这一行 https://github.com/v2fly/v2ray-core/blob/fc6ae4d4e7f5158d7222a42c749d2bf7ca913632/app/dns/dns.go#L101 大体的逻辑是从json文件构造了一个dns struct，然后这个dns里面有个domainMatcher，作用是上面的match，有个clients和matcherInfos，作用是把json dns里面除了host外的servers里面的rule收进去做match。 然后很显然完全没有管dns.servers里面的每一个server block的顺序，全部扔给 https://github.com/v2fly/v2ray-core/blob/fc6ae4d4e7f5158d7222a42c749d2bf7ca913632/common/strmatcher/indexmatcher_linear.go#L42 而这里是直接按照这个顺序： https://github.com/v2fly/v2ray-core/blob/fc6ae4d4e7f5158d7222a42c749d2bf7ca913632/common/strmatcher/indexmatcher_linear.go#L44-L47 拼接上的 更具体的我实在读不下去了。目前确认了json-dns-host里面的内容没有应用到json-dns-servers里面，而servers里面的内容也没有按照block的顺序去做match匹配，而是按照一个手写的根据domain规则类型去排顺序。 看看有没有大神能给改一改，感觉最好是当时写这一块的改一下，会比较得心应手。不知道是不是我的方法不对，找各种reference/definition的时候非常难。

他这个parser确实有问题。希望能更新库。

从我的实际使用观感来看目前不会。 你的某一个outbound失效有可能是服务端彻底挂了，也可能是碰到问题、修复一下就好了，也可能是服务器维护重启，过了2、3分钟自己就好了，也可能是网络传输中丢包了、过几秒钟重连就好了。那么v2应该暂停这个outbounds多长时间合适呢？

把"ip": "0.0.0.0",这一行删除试试

我自己试了一下，inbound listen是127.0.0.1 protocol socks5，outbound是freedom. IDM下载https图片。 结果是可以下载。 proxy/socks: failed to read request > read tcp 127.0.0.1:1090->127.0.0.1:59869: wsarecv: An existing connection was forcibly closed by the remote host. 这一句会出现，但是不影响实际连接/下载成功。 会不会跟你监听本地ipv6地址有关？试一试监听本体ipv4的127.0.0.1？

> > 我自己试了一下，inbound listen是127.0.0.1 protocol socks5，outbound是freedom. IDM下载https图片。 结果是可以下载。 proxy/socks: failed to read request > read tcp 127.0.0.1:1090->127.0.0.1:59869: wsarecv: An existing connection was forcibly closed by the remote host. 这一句会出现，但是不影响实际连接/下载成功。 会不会跟你监听本地ipv6地址有关？试一试监听本体ipv4的127.0.0.1？...

几点建议，与大家讨论： 1. 首先，我觉得应该承认，这个列表大部分使用者是大陆用户，还有部分伊朗等国家，主要是为了突破本地的网络封锁使用。可能会有些海外华人用于回国节点看视频，但是他们大部分都是看的时候开代理，看完了关代理。 做列表，应该从用户实际使用的角度出发。当然也需要考虑利于维护的问题。 2. 因此，目前的category结构，其实主要有利于开发者进行维护，对于用户的实际使用，作用并不大。绝大多数用户是直接geosite:cn, geolocation-!cn这样用的。很多用户都是小白，连设置都不会，都是使用app/模板/脚本预设的规则。 我能想到对于用户category的有用情景，大概就是类似于大陆用户需要访问在大陆和境外都有接入点的境外接入点的公司，比如玩外服游戏。这个需求其实比较小众，但是总归是category结构在面对用户时有用的一个案例。用户实际使用中可以开两个本地代理端口，各使用不同规则，玩游戏的和不玩游戏的。 3. 3.(1) 从这个角度看，我认为@attr应该按照特定地域用户能否连接这个域名、能否快速稳定的连接访问为基础分类。以大陆用户访问A域名举例：能够在大陆地区快速稳定访问A域名的，设一个@attr，如@cn-L1；能稳定访问，但因接入点在境外，并且CDN较差，导致实际访问速度慢的，设@cn-L2；不能稳定访问，时灵时不灵，根据用户需求，不设@attr或设@cn-L3。其他的国家，比如伊朗，也是一样，比如@ir-L1, @ir-L2。对于在全世界都有接入点的，可以用前面提到的anycast的思路，设@all-L1, @all-L2. 3.(2) 在给终端用户的编译/打包的文件（.dat）里面，应该是选择L2自动包含L1，选择L3自动包含L2、L1，选择all自动包含cn、ir这样的。如果把某个category标记某@attr，那么该category下的所有域名都应该自动具有该@attr。 3.(3) 我举例几个使用场景，是需要/适合这种方式的。比如OneDrive，网页版国内不能访问，但是手机app和电脑端的windows自带同步软件则可以访问，而且有时候可能会有大流量的上传下载。那么多数用户，会希望访问网页OneDrive走代理，访问应用/软件的域名走直连。对于少部分需求特殊的用户，也可以自己加一个geosite:onedrive@cn-L3走代理的规则。还有像大陆用户玩暴雪的外服游戏，访问网页下载客户端都希望走境外接入，但是下载游戏的数据流量则希望走暴雪大陆境内的接入点，既快速又节省代理流量。还有下载windows update，ios里面itunes music/movie等。 3.(4) 那么，对于绝大多数大陆小白而言，设置规则也更简单了：无非是geosite:all@cn-L1或geosite:all@cn-L2。 4. 利用多@attr的体系，让各个国家需要此列表的网友自发为列表提交更新。不要想着几个开发者就把所有的事情搞定。“@cn能不能服务这群人，是不是不能服务那群人”的问题，也就差不多解决了。 5. 这样的话，目前的编辑/架构方式，是不是需要改一改？我提一个思路：数据采用数据库的方式存放，外部接一个webhost，用于提交、审核修改。相当于，category是一个分类的（树状）维度，@attr是一个维度体系，内涵可交叉的多（树状）维度。多维度并存，可能还是数据库的方式更好一些？实际上，一个特定的用户选择，就是geosite: category:aaa + attr:bbb。

> > 这么多的 attr，没有量化的标准能够确定一个域名应该给什么 attr，而且给出的属性只能反映维护者个人的网络环境，并不适合做到这个项目里。前半部分导致维护成本高得离谱，难以落实；后半部分直接违背了这个项目的内容应该适合所有人使用的原则。 > > 本身这个项目也是接受任何人为列表提交更新的。开发者的工作不体现在列表维护上，在于生成各类型数据库的代码维护上。你的理解有误。 假设你后半句话指的是维护者，那么维护者的工作在于把关，确保每个共享者的提交都符合这个项目的维护原则，不能每个人都按照自己的理解和对自己方便的样子来改。 > > 考虑你这个想法落实起来的工作量，可能在这个项目上做修改还不如直接开新的项目。 我不评价你这个思路的好坏，因为只有做了才知道。但是我建议你先多从更新列表的贡献做起，加深对这个项目的了解。等积累一定的经验以后再重新构思这个项目应该如何改进。 是的，开发者和维护者应该被分为两个群体；开发者做架构，维护者做内容维护，这样思路就清晰了。 我提出的其实主要就是关于“应该适合所有人使用的原则”这个问题。这方面，我认为应该从用户需求、群体、需求群体出发，去考虑和设计。要看现实中哪些用户在用。做一个项目，一个功能，一种架构思路，没有真正的用户在用，那就没意义。从用户的角度出发，事情就简单了：有一批大陆需要翻墙的用户；有一批伊朗要翻墙的用户；有一批要使用境外企业服务、玩外服游戏的用户；有一批境外想要看大陆视频的用户。可能还有一些需求群体。那么除了这个列表的需求群体，可以说就没有人再去使用这个列表了，也因此没必要为更宽广的使用场景设计列表结构。 关于attr的标准，以及“只能反映维护者个人的网络环境”，我不同意你的看法。我的想法是，按照用户群体，由用户自发进行维护。把维护分成审核和提交（其实现在就是）。维护群组可以采取树状结构，上层级对应更广的地域/领域，具备更多的审核权限，下级的群组更具体，比如专门维护海外用户访问大陆视频。那么大陆用户的维护审核群组很容易去判断，哪个域名在大陆有接入点，应该作为cn-L1，哪个外部有接入点、并且大陆用户愿意去直连，作为cn-L2，哪个能直连，但代理更快，作为cn-L3。上层级的审核维护也许难以为全部人做出好规则，但是可以有下层级的审核维护群组代表更具体的用户群，做出的维护就能更好。 从这个思路延展，甚至可以发展出“适合河南移动直连的域名”之类的细分类别----是否发展出，就可以全凭用户是否有需求，进而是否有人愿意主动去维护来决定了。开发者更省心，上层级的审核维护也更省心。从这个角度讲，其实也“适合所有人了”：有需求的用户按需求群组自发贡献规则；没有需求、不需要使用这个列表的，自然也不用去管。 从这个角度讲，可能确实新开一个项目更合适；但是这里我想是与大家讨论。是否去做、是否开新项目这些，想好了考虑周全了再行动。