关于这个autogen的使用

[MaurUppi]

抱歉几个问题请教

1. 是强绑定dler机场的吗？
2. 访问IP 与 机场的节点之间是怎么匹配的？ 例如机场欧洲有个英国，访问的IP是法国，预期结果是怎样呢？
3. README上主要写的是启用方式，但实现逻辑没有怎么写，所以还没太搞明白是否适合/是否机场通用等问题

谢谢！

[JohnnySun]

@MaurUppi

1. 并不是强制绑定Dler的机场，只是我自己在用Dler家的机场，所以provider那边我现在只给Dler做了适配，如果有别的机场，理论上需要对provider做重新的适配
2. 第二个问题 IP与机场节点的匹配是通过 priority_routing实现的，这里实际上按大洲，国家分配配置了优先路由， 比如 德国，如果配置了德国路由，就会优先使用德国的路由配置，如果没有德国的路由配置，会转而使用欧洲的默认路由配置。 关于每一个大洲的路由配置 在这里 每个大洲的默认路由配置 link
3. 如果你想替换成别的机场，其实你只需要处理下这里就行 link

关于个人的复写配置：

路由规则，很多人会有自己的私有路由配置，而这部分是不应该被暴露到public repo上的，会导致一些隐私泄露问题。你也可以根据Readme，去创建一个私有的仓库，需要复写，或者增加的配置，直接按照这个工程的目录结构放置就好了，CI生成前会先CP一次。

更细节一些实现方式：

其实本质上还是要拼接成一个符合 Clash/Mate/Stash 语法的 YAML/JSON 但是一个过于复杂且冗长的配置文件是不便于维护的。所以这个工程本质上还是把YAML拆分，配合上正则进行一些替换操作，最后在拼接成一个真正的YMAL文件。处理的脚本在这里 link 可能看一下这个会更便于你的理解

[MaurUppi]

@MaurUppi

1. 并不是强制绑定Dler的机场，只是我自己在用Dler家的机场，所以provider那边我现在只给Dler做了适配，如果有别的机场，理论上需要对provider做重新的适配
2. 第二个问题 IP与机场节点的匹配是通过 priority_routing实现的，这里实际上按大洲，国家分配配置了优先路由， 比如 德国，如果配置了德国路由，就会优先使用德国的路由配置，如果没有德国的路由配置，会转而使用欧洲的默认路由配置。 关于每一个大洲的路由配置 在这里 每个大洲的默认路由配置 link
3. 如果你想替换成别的机场，其实你只需要处理下这里就行 link

关于个人的复写配置：

路由规则，很多人会有自己的私有路由配置，而这部分是不应该被暴露到public repo上的，会导致一些隐私泄露问题。你也可以根据Readme，去创建一个私有的仓库，需要复写，或者增加的配置，直接按照这个工程的目录结构放置就好了，CI生成前会先CP一次。

更细节一些实现方式：

其实本质上还是要拼接成一个符合 Clash/Mate/Stash 语法的 YAML/JSON 但是一个过于复杂且冗长的配置文件是不便于维护的。所以这个工程本质上还是把YAML拆分，配合上正则进行一些替换操作，最后在拼接成一个真正的YMAL文件。处理的脚本在这里 link 可能看一下这个会更便于你的理解

鉴于还没开始细看，所以细节问题暂时没有。

不过，，话说，你现阶段的工程是没有适配 Surge 是吗？
我倒是有在用，，，不知道改造成Surge可用的，有多少工作量。。

[JohnnySun]

@MaurUppi

1. 并不是强制绑定Dler的机场，只是我自己在用Dler家的机场，所以provider那边我现在只给Dler做了适配，如果有别的机场，理论上需要对provider做重新的适配
2. 第二个问题 IP与机场节点的匹配是通过 priority_routing实现的，这里实际上按大洲，国家分配配置了优先路由， 比如 德国，如果配置了德国路由，就会优先使用德国的路由配置，如果没有德国的路由配置，会转而使用欧洲的默认路由配置。 关于每一个大洲的路由配置 在这里 每个大洲的默认路由配置 link
3. 如果你想替换成别的机场，其实你只需要处理下这里就行 link

关于个人的复写配置：
路由规则，很多人会有自己的私有路由配置，而这部分是不应该被暴露到public repo上的，会导致一些隐私泄露问题。你也可以根据Readme，去创建一个私有的仓库，需要复写，或者增加的配置，直接按照这个工程的目录结构放置就好了，CI生成前会先CP一次。
更细节一些实现方式：
其实本质上还是要拼接成一个符合 Clash/Mate/Stash 语法的 YAML/JSON 但是一个过于复杂且冗长的配置文件是不便于维护的。所以这个工程本质上还是把YAML拆分，配合上正则进行一些替换操作，最后在拼接成一个真正的YMAL文件。处理的脚本在这里 link 可能看一下这个会更便于你的理解

鉴于还没开始细看，所以细节问题暂时没有。

不过，，话说，你现阶段的工程是没有适配 Surge 是吗？ 我倒是有在用，，，不知道改造成Surge可用的，有多少工作量。。

我之前其实也是同时维护这两套配置的 QuantmultX/Clash， 后来发现这样成本实在是太高了，每一个规则的修改，都需要完全兼顾两边，也就是要写两次。
而且最头疼的事情，其实是QuantmultX/Clash/Surge他们的配置还不完全对齐。有的时候要实现一个feature，兼容问题实在是太让人头疼了。后来我其实是做了一次配置整合。 把我的所有代理全部都换成了Clash配置。 Android是Meta iOS/Mac是stash。 这样我至少可以使用clash的标准写一个基础的配置。 这其实也是我最开始做这个事情的起因