[Discuss] About new category `geolocation-global`(Temp name) #91

akiirui · 2020-07-29T08:20:33Z

由于之前有用户提出了部分Google服务大陆可直连，DLC中能否区别开来？ #487, 于是才有了本次的讨论.

由于主要讨论内容所在的 PR #88 已合并, 于是单独开一个 Issues 进行相关讨论.

以下内容仅为个人提出的意见, 大家可以提出意见进行修改.

更改geolocation-!cn的定义为“在中国大陆外拥有连接点的域名列表”

@cn定义为“在中国大陆拥有连接点的境外域名”，用于geolocation-!cn及其包含的子列表，建立geolocation-global收集这类域名

@!cn定义为“在中国大陆外拥有连接点的境内域名”，用于geolocation-cn及其包含的子列表，同样收集于geolocation-global（我猜测，需要用到此类域名的用户较少，标记工作可以延后）

新增include:list@attr这种包含方式

把这几条综合简化一下, 可以将其拆分为 3 个大分类

geolocation-cn: 中国大陆公司所属的域名列表
geolocation-!cn: 境外公司所属的域名列表
geolocation-global^暂命名: 在中国大陆与其境外均有可用连接点的的域名列表
- 主要包含模棱两可的域名, 例如中国公司所属但对境外提供主要服务的域名, 或境外公司所属但在中国有可用连接点的域名
- 其中境外公司所属但在中国有可用连接点的域名, 标记为 @cn^待定
- 其中中国公司所属但对境外提供主要服务的域名, 标记为 @!cn^待定

这样就可以同时满足境内境外的用户需求, 用户可以自行选择 geolocation-global[@cn|@!cn] 直连或代理.

现在的可用方式为:

中国用户, 仅代理中国大陆外的公司所属的域名列表:

CN User -> (Optional)(Direct global) -> CN
           (Optional)(Proxy  global) -> Outside
                     (Proxy     !cn) -> Outside
                     (Direct    all) -> CN

中国用户, 代理中国大陆内的公司所属的域名列表以外的域名:

CN User -> (Optional)(Direct global) -> CN
           (Optional)(Proxy  global) -> Outside
                     (Direct     cn) -> CN
                     (Proxy     all) -> Outside

境外用户, 仅代理中国大陆内的公司所属的域名列表:

!CN User -> (Optional)(Direct global) -> Outside
            (Optional)(Proxy  global) -> CN         #这个完全没有必要
                      (Proxy      cn) -> CN
                      (Direct    all) -> Outside

^: 由于 v2ray 的 routing rules 优先级的关系.只要使用了 global 的 rules 在 !cn 前面, 即使 global 内的域名被 !cn 包含了也没关系.

执行方式大概如下:

以上面的3个分类定义整理 geolocaion-cn 和 geolocation-!cn 中包含的域名.
- 其确定的分类定义可以再慢慢进行讨论
整理在中国大陆与其境外均有可用连接点的域名列表至 <company-name>-global.
- 可参考 #89
- 也可以不创建 <company-name>-global 而在其原本 <company-name> 中以 @attr 实现
创建新的大分类 geolocation-global^暂命名, 整合所有 <company-name>-attr.
- 如使用 @attr 实现则可以 include:<company-name>@attr

以上的方式工程量会比较少, 只需要为相关的条目添加 @attr 即可.

部分列表末尾放置有CDN，其域名不一定属于列表的实体。以上方案并未考虑这种特殊情况，但个人认为可以采取相同手段

如果其 CDN 同时提供境内境外接入点那么按照上面的可以直接添加 @global

标记流程是否能自动化？例如 #54 中提及的域名校验功能

可行, 可以分析境外公司所属域名解析到的 IP 结果, 如果中国大陆 DNS 返回的 IP 在 geoip:cn 内就可以为其标记 @global

geolocation-global名称是否合适？如果合适，是否要将@cn及@!cn合并为@global？

命名方面, 以我上面的分类定义来说, 包含的域名是来自境外公司所属但在中国有可用接入点的域名.
其实用 geolocation-cn-available 比较合适, 不过太长了...
参考 !cn 可以简化为 geolocation-&cn 或者 ~cn 之类的可能比较好.

在有@cn、@!cn的情况下，如果新增@dl来标记系统、软件、游戏的下载、更新域名，还有意义吗？

@dl 应该用处不大, 境内用户下载境外内容如果不经过代理速度极慢几乎不可用.
而下载境内的内容由于 geolocaion-cn 直接直连也不需要 @dl.

Jul 29, 16:00. 补充遗漏, 且按下文修改上文的部分内容.

geolocation-global^暂命名里也应该分两小类:

中国大陆公司所属但对境外提供主要服务的域名, 标记 @!cn^待定
- 例 data/alibabacloud
境外公司所属但在中国大陆有可用连接点的域名, 标记 @cn^待定
- 例 full:fonts.googleapi.com

当前某些域名被 geolocation-cn 和 geolocation-!cn 同时包含, 例:

geolocation-cn  <- include:alibaba <- include:alibabacloud
geolocation-!cn <- include:alibabacloud

新的类别 geolocation-global^暂定目的就是解决这些模棱两可的规则冲突.
同样以 alibabacloud 为例.
从 alibaba 中删除 alibabacloud,
为 alibabacloud 内的域名标记 @!cn,
为 geolocation-global 添加 alibabacloud

geolocation-cn     <- include:alibaba
geolocation-!cn    <- include:alibabacloud
geolocation-global <- include:alibabacloud

这样就解决了冲突, 且用户可用以 geolocaion-global@!cn 覆盖 cn 或 !cn 选择直连或者代理相关域名.
而不是由于重复的归属于 cn 和 !cn 导致意外发生.

The text was updated successfully, but these errors were encountered:

akiirui · 2020-07-29T08:46:28Z

我觉得保持足够简单可能比较好，忽略某些域在国内有CDN这些需求。
可以建立一个单独属于cdn厂商的列表，再深入的让用户单独添加这些路由。
（头有点晕，等到晚上看正文

我一开始也是这么想的...
但是自从 v2ray/domain-list-community#487 有用户提出了这个问题之后.
新添加的规则 0971cd4 影响到了我的使用. 于是就想既然都添加进来了, 那就把它规范化...
最终还是看讨论结果, 这里只是一个如何规范化相关域名列表的讨论~

Robot-DaneelOlivaw · 2020-07-29T10:14:48Z

补充一下讨论背景：

现在希望解决的问题是，部分域名在中国大陆境内外均有连接点，但其属于境外企业或组织、包含在geolocation-!cn中，所以没办法进行单独处理。日前 #79 修复了标签功能，允许使用@attr对这类域名进行标记，因此可以开始讨论出一个具体解决方案了。

目前希望使用@cn对geolocation-!cn及其包含子列表中的域名进行标记，并整理成一个单独的列表geolocation-global。

我的提议（详见#88）：

更改geolocation-!cn的定义为“在中国大陆外拥有连接点的域名列表”
@cn定义为“在中国大陆拥有连接点的境外域名”，用于geolocation-!cn及其包含的子列表，建立geolocation-global收集这类域名
@!cn定义为“在中国大陆外拥有连接点的境内域名”，用于geolocation-cn及其包含的子列表，同样收集于geolocation-global
新增include:list@attr这种包含方式

如此更改不再违背列表的定义，不必再新增notinclude:这种包含方式，用户更容易理解、编写路由规则。

此外，有些需要注意的要点：

目前应该先着眼处理@cn（仅考虑境内用户的使用场景），@!cn的逻辑是相同的，而CDN的问题可以在@cn解决后再来讨论
原则是简洁、易于理解、无需时常维护、不必新增过多功能、避免日后改动
不应迁就路由规则而删除某些应该存在的域名，如alibabacloud的确属于alibaba，那后者就应包含前者

Loyalsoldier · 2020-07-29T10:20:14Z

我先尝试阅读 V2Ray DNS 部分的源码，看看能不能找出规则处理的优先级的 bug。找到的话，先修 bug，这样通过 DNS 配置就可以避免用 V2Ray 做网关、当透明代理时的解析问题。

非网关和非透明代理的问题其实是比较好解决的，只要不在 routing 中的 domain 规则中配置 IP 规则，在 geosite.dat 中的域名就不会用到 V2Ray 的 DNS 模块进行解析。只要配置合理的规则上下前后关系，就没啥大问题。

只是说，做好了域名分类规范后，routing 中可以少写几条规则，方便用户。

kslr · 2020-07-29T10:25:17Z

我先尝试阅读 V2Ray DNS 部分的源码，看看能不能找出规则处理的优先级的 bug。找到的话，先修优先级 bug，这样通过 DNS 配置就可以避免用 V2Ray 做网关当透明代理时的解析问题。

这个是什么

Loyalsoldier · 2020-07-29T10:31:14Z

我先尝试阅读 V2Ray DNS 部分的源码，看看能不能找出规则处理的优先级的 bug。找到的话，先修优先级 bug，这样通过 DNS 配置就可以避免用 V2Ray 做网关当透明代理时的解析问题。

这个是什么

"dns": {
  "servers": [
    {
      "address": "https+local://dns.alidns.com/dns-query",
      "domains": [
        "geosite:cn",
        "geosite:google@cn",
        "full:fonts.googleapis.com"
      ]
    },
    {
      "address": "https://1.1.1.1/dns-query",
      "domains": [
        "geosite:geolocation-!cn"
      ]
    },
    "223.5.5.5"
  ]
}

由于现在域名 font.googleapis.com 同时在 google@cn 和 geolocation-!cn 中。

当 V2Ray 做网关或者透明代理时，使用上面这样的 DNS 配置，解析 font.googleapis.com 会大概率使用 1.1.1.1，当这个解析失败，才会使用 dns.alidns.com

Robot-DaneelOlivaw · 2020-07-29T18:38:53Z

geolocation-global^暂命名里也应该分两小类:

中国大陆公司所属但对境外提供主要服务的域名, 标记 @!cn^待定

境外公司所属但在中国大陆有可用连接点的域名, 标记 @cn^待定

根据文档，生成文件时会将include:替换为列表的真实内容：

Replace include: lines with the actual content of the file.

那如果实现了include:list@attr这一功能，子列表中的标签也应该会被继承下来，即geolocation-global会有标记好的@cn和@!cn，那这两小类就自然分类完成，可以用您提及的geolocation-global[@cn|@!cn]来表示。

同样以 alibabacloud 为例.
从 alibaba 中删除 alibabacloud,
为 alibabacloud 内的域名标记 @!cn,
为 geolocation-global 添加 alibabacloud

用户可用以 geolocaion-global@!cn 覆盖 cn 或 !cn 选择直连或者代理相关域名.

既然可以用geolocaion-global@!cn进行覆盖，那就没有必要从alibaba中删除alibabacloud了。除此之外我认为您这一方案是比较优雅的。

标签名称@cn和@!cn都是本项目过去一直存在的术语，继续沿用会比较容易理解，也比较符合它们的用途。至于列表名称，新增的这一列表是geolocation-cn与geolocation-!cn并集的子集，仍可以称作geolocation；global虽然并不贴切，但胜在简短，如果要找替代选项，也用一个单词来表达为优。

Robot-DaneelOlivaw · 2020-07-29T19:39:50Z

当 V2Ray 做网关或者透明代理时，使用上面这样的 DNS 配置，解析 font.googleapis.com 会大概率使用 1.1.1.1，当这个解析失败，才会使用 dns.alidns.com

观察了一下，V2Ray会选择符合规则的最后一个DNS。

Loyalsoldier · 2020-07-30T00:48:33Z

观察了一下，V2Ray会选择符合规则的最后一个DNS。

你不说我还没发现，测试了一下，好像还真是这样。但是我昨天看了代码，并没有发现这个规则 😓

akiirui · 2020-07-31T03:19:26Z

截至此回复为止, 各位都提出了几点不同的意见, 其中与本主题冲突的几点:

不应迁就路由规则而删除某些应该存在的域名，如 alibabacloud 的确属于 alibaba，那后者就应包含前者

这个是我考虑不周, 不应该迁就 global 删改其他规则.

例子在这里引用得可能不太恰当, 但的确应该修改.
(因为这是整个列表里唯一一个同时 include: 在 cn 和 !cn 中的一个域名列表)
不过这个问题属于 #28 所讨论的范围, 这里就不讨论这个问题了.

至于列表名称，新增的这一列表是 geolocation-cn 与 geolocation-!cn 并集的子集，仍可以称作 geolocation.

至于这个新列表的名称, global 意为 全球, 而这个列表主要包含的是:

!cn 中, 境外公司所属但在中国大陆有可用接入点的的域名
cn 中, 中国公司所属但对境外提供主要服务的域名

使用 global 就有点不太贴切, 且:

目前应该先着眼处理@cn（仅考虑境内用户的使用场景）

我们是否可以在此新列表中完全忽略 @!cn, 将这个列表的用户限定为境内用户. 如果这样, 名称就可以命名为 with-cn

又或者不创建这个新的列表, 仅在其主体列表内为相关的域名添加 @cn 然后让有需求的用户使用 geosite:list@cn 或 geosite:list@!cn:

data/geolocation-!cn:
    include:adidas
        adidas.com.cn @cn
        ...
    include:google
        full:fonts.googleapi.com @cn
        ...
    ...

data/geolcation-cn:
    include:alibaba
        include:alibabacloud
            alicloud.com @!cn
            ...
        ...
    ...

{
  "type": "field",
  "outboundTag": "direct",
  "domain": [
    "geosite:geolocation-cn",
    "geosite:geolocation-!cn@cn"
  ]
},
{
  "type": "field",
  "outboundTag": "proxy",
  "domain": [
    "geosite:geolocation-!cn",
    "geosite:geolocation-cn@!cn",
  ]
}

这样既保持了简单性, 让用户了解这条规则的含义. 也不需要修改 main.go 新增 include:list@attr 包含方式.

^注: 上面用例子中的 alibabacloud 均包含在 cn 和 !cn, 这个冲突需要解决.

甚至可用更简单化一点, 一切保持原样, 不添加 @attr, 为其创建一个新列表:

data/google-cn:
    full:fonts.googleapi.com
    ...

{
  "type": "field",
  "outboundTag": "direct",
  "domain": [
    "geosite:geolocation-cn",
    "geosite:google-cn"
  ]
},
{
  "type": "field",
  "outboundTag": "proxy",
  "domain": [
    "geosite:geolocation-!cn",
  ]
}

从本次讨论看出, 目前的域名分类有着定位不准的问题, 还有过于滥用 include:.

这些问题都需要在 #28 中讨论解决.

Robot-DaneelOlivaw · 2020-07-31T09:12:17Z

这样既保持了简单性, 让用户了解这条规则的含义. 也不需要修改main.go新增include:list@attr包含方式.

这个想法提醒了我，在子列表中标记@cn并且包含在geolocation-!cn中，生成文件时域名就已经拥有标签。经测试，geosite:geolocation-!cn@cn是包含这类域名的。那工作就可以进一步简化，只需添加@cn，而无需建立geolocation-global、也无需新增include:list@attr了。

^注: 上面用例子中的 alibabacloud 均包含在 cn 和 !cn, 这个冲突需要解决.

为alibabacloud标记@!cn，在路由规则中优先级较高处进行特殊处理或许可以解决问题？

甚至可用更简单化一点, 一切保持原样, 不添加@attr, 为其创建一个新列表

我担心若要为所有在中国大陆拥有连接点的境外企业/组织建立列表，数量会过多。另外@attr的好处是可继承，例如在alibabacloud中标记了@!cn，可以从geosite:geolocation-cn@!cn、geosite:alibaba@!cn、geosite:alibabacloud@!cn三个层级对这些域名进行路由规则配置。

akiirui · 2020-08-03T01:06:03Z

由于已经以讨论内容对新增内容作出了修改, 此讨论应该可以关闭了.

Loyalsoldier mentioned this issue Jul 29, 2020

关于域名分类数据的讨论 #28

Open

This comment has been minimized.

Sign in to view

IceCodeNew mentioned this issue Jul 30, 2020

Create bridgestone #93

Merged

akiirui closed this as completed Aug 3, 2020

Loyalsoldier mentioned this issue Aug 9, 2020

Proposal for resolving local domain in built-in DNS v2fly/v2ray-core#88

Closed

Vigilans mentioned this issue Aug 10, 2020

Proposal for amending domain matching logic v2fly/v2ray-core#92

Closed

Robot-DaneelOlivaw added the data structure Discussion about format of directories and files label Aug 10, 2020

IceCodeNew mentioned this issue Aug 18, 2020

Create lenovo #158

Closed

Robot-DaneelOlivaw mentioned this issue Sep 28, 2020

attr 类型没有被正确处理 #235

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Discuss] About new category `geolocation-global`(Temp name) #91

[Discuss] About new category `geolocation-global`(Temp name) #91

akiirui commented Jul 29, 2020 •

edited

Loading

This comment has been minimized.

akiirui commented Jul 29, 2020

Robot-DaneelOlivaw commented Jul 29, 2020 •

edited

Loading

Loyalsoldier commented Jul 29, 2020 •

edited

Loading

kslr commented Jul 29, 2020

Loyalsoldier commented Jul 29, 2020 •

edited

Loading

Robot-DaneelOlivaw commented Jul 29, 2020 •

edited

Loading

Robot-DaneelOlivaw commented Jul 29, 2020

Loyalsoldier commented Jul 30, 2020

akiirui commented Jul 31, 2020 •

edited

Loading

Robot-DaneelOlivaw commented Jul 31, 2020

akiirui commented Aug 3, 2020

[Discuss] About new category geolocation-global(Temp name) #91

[Discuss] About new category geolocation-global(Temp name) #91

Comments

akiirui commented Jul 29, 2020 • edited Loading

This comment has been minimized.

akiirui commented Jul 29, 2020

Robot-DaneelOlivaw commented Jul 29, 2020 • edited Loading

补充一下讨论背景：

我的提议（详见#88）：

此外，有些需要注意的要点：

Loyalsoldier commented Jul 29, 2020 • edited Loading

kslr commented Jul 29, 2020

Loyalsoldier commented Jul 29, 2020 • edited Loading

Robot-DaneelOlivaw commented Jul 29, 2020 • edited Loading

Robot-DaneelOlivaw commented Jul 29, 2020

Loyalsoldier commented Jul 30, 2020

akiirui commented Jul 31, 2020 • edited Loading

Robot-DaneelOlivaw commented Jul 31, 2020

akiirui commented Aug 3, 2020

[Discuss] About new category `geolocation-global`(Temp name) #91

[Discuss] About new category `geolocation-global`(Temp name) #91

akiirui commented Jul 29, 2020 •

edited

Loading

Robot-DaneelOlivaw commented Jul 29, 2020 •

edited

Loading

Loyalsoldier commented Jul 29, 2020 •

edited

Loading

Loyalsoldier commented Jul 29, 2020 •

edited

Loading

Robot-DaneelOlivaw commented Jul 29, 2020 •

edited

Loading

akiirui commented Jul 31, 2020 •

edited

Loading