geolocation-!cn: add @cn attribute for .cn domains in geolocation-!cn category

[Loyalsoldier]

No description provided.

[IceCodeNew]

domain:csgo.wmsj.cn
domain:dota2.wmsj.cn
domain:st.dl.bscstorage.net
domain:st.dl.eccdnx.com
domain:st.dl.pinyuncloud.com
domain:steam.ksyna.com
domain:steampowered.com.8686c.com
domain:steamstatic.com.8686c.com

上面是所有 steam 在国内的 CDN 域名规则，建议为它们都补充上 @cn 属性。

[IceCodeNew]

steam 类下一些域名也可以加上 @cn 属性，详细见上一条评论。

---

BTW steam 下载内容时也会用到 domain:lancache.steamcontent.com 这一条域名，这一项绝对应该放在 direct 规则里，但不适合冠以 @cn 属性，看大家的意见了。

[Loyalsoldier]

目前，我的想法倾向于：

大陆公司/组织，默认加入到 geolocation-cn；非大陆的，默认加入到 geolocation-!cn

1. 对于在 geolocation-!cn 中，加入了的 .cn 结尾的域名，用 @cn attr 标记
2. 对于在 geolocation-!cn 中，在大陆可直连、且速度比较好的域名，用 @direct attr 标记（主要用于处理 apple 和 Google 列表。不建议对 geolocation-!cn 内的所有列表都标记一遍）
3. @cdn 专门用于不知道是直列还是代理的 CDN 域名，让用户自己配置。

attr 可以并列使用。

另外，@direct 参照这里：#89

[EpLiar]

按照工作量来说，可能加 blocked 会比 direct 轻松一些？

[Loyalsoldier]

BTW steam 下载内容时也会用到 domain:lancache.steamcontent.com 这一条域名，这一项绝对应该放在 direct 规则里，但不适合冠以 @cn 属性，看大家的意见了。

domain:lancache.steamcontent.com 这个域名，DNS 解析都是西雅图的 IP 哎

[IceCodeNew]

1. 对于在 geolocation-!cn 中，加入了的 .cn 结尾的域名，用 @cn attr 标记

我觉得这里就是我们工作做偏了的地方，geolocation-!cn 照理来说应该包含的是没有国内接入点的网站服务，但是因为 include 其他的域名分类文件，而这些子类在维护时却是以尽可能全的考虑来维护，就会导致混入其实接入点在国内的域名。

这样的局面应该要尽快改正过来，不然 geolocation-!cn 这个分类实际就没有任何实用价值。

[IceCodeNew]

domain:lancache.steamcontent.com 这个域名，DNS 解析都是西雅图的 IP 哎

这个域名不应该看解析结果，而是应该从名字上去理解了。
关于这个域名实际的应用，请参考这篇文章：https://lancache.net/news/2020/01/14/steam-client-now-supports-lancache/

[EpLiar]

这样的局面应该要尽快改正过来，不然 geolocation-!cn 这个分类实际就没有任何实用价值。

我建议维持原样。

如果一个文件中包含了国内和国外，那是包含在哪里？还是干脆就不包含？完全的分开水和油本身就是不容易的一件事。

所以我的观点是，国外企业/公司/组织依旧在 !cn，国内在 cn。

[IceCodeNew]

如果一个文件中包含了国内和国外，那是包含在哪里？还是干脆就不包含？完全的分开水和油本身就是不容易的一件事。

我的意思是说，改变 include: 的语法，这样以后 geolocation-cn 里可以 include:google@cn 这样来包含接入点在国内的域名。

而 geolocation-!cn 这边，也应该有类似 notinclude:google@cn 这样的方式，来仅包含 google 文件里不含中国接入点的域名。

[EpLiar]

而 geolocation-!cn 这边，也应该有类似 notinclude:google@cn 这样的方式，来仅包含 google 文件里不含中国接入点的域名。

那看来是先包含再剔除的形式，需要上游支持。

[Loyalsoldier]

我先想想这种新语法好不好实现。

[akiirui]

我的意思是说，改变 include: 的语法，这样以后 geolocation-cn 里可以 include:google@cn 这样来包含接入点在国内的域名。

我个人认为这些在中国大陆有可用 CDN 的域名不应该包含在 geolocation-cn 内.

应该单独开一个类似于 category-ads 的分类来整合这些域名, 让有需要且了解相关配置的用户使用 geosite:google@direct (Ref #89) 或者 geosite:category-direct / geosite:category-available-cn (例)

因为这些域名通过不同的公共 DNS 服务解析出来的 IP 不一定能够直接访问, 可能会导致使用 geosite:cn 的用户碰见奇奇怪怪的问题.
(我之前提出这个问题的时候就是因为使用 Cloudflare DoT 解析 fonts.googleapi.com v2ray 却直连导致 timeout 才发现的.)

而 geolocation-!cn 这边，也应该有类似 notinclude:google@cn 这样的方式，来仅包含 google 文件里不含中国接入点的域名。

这个部分其实可以通过两条 routing rules 在 v2ray client 处理, 没必要让 DLC 复杂化:
(甚至之后有了新的分类, geosite:google@direct 可以替换为 category-xxx 以简化 domain 内容)

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

[Loyalsoldier]

众口难调 🙈

[akiirui]

众口难调 🙈

是的 所以才在这里提出建议。
其实这几种方法都差不多。只是应用到 routing 时多一条少一条 rules 的区别罢了。

[Robot-DaneelOlivaw]

因为这些域名通过不同的公共DNS服务解析出来的IP不一定能够直接访问, 可能会导致使用geosite:cn的用户碰见奇奇怪怪的问题.

中国大陆境内外均有连接点的域名，境内用户希望它们加入geolocation-cn，境外用户则希望它们加入geolocation-!cn。

• 如果两个列表都包含这类域名，则可以通过调整路由规则优先级来决定是否直连，但需要用户对域名列表的内容有足够的了解。

• 如果仅geolocation-!cn包含这类域名、用@cn标记（即现阶段的状况）并整理为geolocation-global，则可以直接为这类域名选择所需路由规则。

• 两种方案皆违背了geolocation-!cn的定义。

中国大陆境内外均有连接点、境外IP无法连接的域名需要路由规则和DNS两方面配合。将其放入geolocation-cn有可能出现问题，反之会变慢。

• 应该采取比较保险的措施，与其它境内外均有连接点的域名作相同处理。

我觉得这里就是我们工作做偏了的地方geolocation-!cn照理来说应该包含的是没有国内接入点的网站服务，但是因为include其他的域名分类文件，而这些子类在维护时却是以尽可能全的考虑来维护，就会导致混入其实接入点在国内的域名。

严格按照定义来说，现在存在在境内有连接点的列表geolocation-cn、只在境外有连接点的列表geolocation-!cn。境内外均有连接点的域名应包含在前者中，后者不包含任何在境内存在连接点的域名。

• 如前所述，将这类域名加入geolocation-cn有可能无法连接

• 因include:特性所限，需要开发新功能将此类域名从geolocation-!cn中剔除

我的想法是：

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

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

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

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

如此更改不再违背列表的定义，不必新增notinclude:这种包含方式，用户更容易理解、编写路由规则。但毕竟增加了一个重要的列表，若日后再对这个列表更名、删除，会导致一大批配置文件失效，希望各位集思广益，想想这种方案有怎样的缺点、会造成怎样的后果。

P.S.

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

• 标记流程是否能自动化？例如 [提议] 引入 geolocation-cn 域名校验功能 #54 中提及的域名校验功能

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

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

[Loyalsoldier]

我想先不管 @cdn 和 steam 的问题，无论最终得出什么方案，这个 PR 都是适合合并的。

[akiirui]

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

1. 更改geolocation-!cn的定义为“在中国大陆外拥有连接点的域名列表”
2. @cn定义为“在中国大陆拥有连接点的境外域名”，用于geolocation-!cn及其包含的子列表，建立geolocation-global收集这类域名
3. @!cn定义为“在中国大陆外拥有连接点的境内域名”，用于geolocation-cn及其包含的子列表，同样收集于geolocation-global（我猜测，需要用到此类域名的用户较少，标记工作可以延后）
4. 新增include:list@attr这种包含方式

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

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

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

现在的可用方式为:

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

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

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

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

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

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

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

---

执行方式大概如下:

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

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

---

部分列表末尾放置有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,
从 geolocation-!cn 中删除 alibabacloud,
为 geolocation-global 添加 alibabacloud 并标记 @!cn

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

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

[Loyalsoldier]

目前只是为 geolocation-!cn 中被 include 的列表中以 .cn 结尾的域名添加 @cn attr，无论最后选用哪个方案。这个 PR 的提交都是合适的，所以先 merge 这个 PR。

暂时搁置 steam、@cdn 的问题，以及接下来方案的选择，取决于是否实现新的 include 语法。