哈哈，其实我也正在研究这个

我在想一个更深远的问题，比如配置文件的域名是否应该也先 strings.ToLower？

或者先不管配置文件（应该没人会大写吧），先给各处收到的域名加 strings.ToLower

比如目前我看了 sniffing 的 tls 以及 fallbacks 判断的 serverName 都是没有这个转换的

哈哈，其实我也正在研究这个

我在想一个更深远的问题，比如配置文件的域名是否应该也先 strings.ToLower？

配置文件我觉得不用管, 并且geo的数据肯定是标准的.

sniffing 的 tls

这个修改对sniffing 有效,因为域名匹配还是这个位置.
fallback...不知道用了什么去匹配了(话说fallback有用匹配规则吗?

PS: 隔壁那个新matcher内存需求较大, 同样规则翻倍起步, 考虑到低配设备, 还是不用了.

sniffing 的 tls

这个修改对sniffing 有效,因为域名匹配还是这个位置.
fallback...不知道用了什么去匹配了(话说fallback有用匹配规则吗?

对 sniffing 新的 domainsExcluded 无效，它是直接判断的，所以嗅探出 tls 的域名是大写的话就绕过了

fallbacks 也是直接 strings.Contains。。。感觉这些是一个系统性 strings.ToLower 工程

domainsExcluded 刚加的...所以他没有使用之前同样的判断规则吗?
fallbacks 可能确实要另外处理了.

PS: 隔壁那个新matcher内存需求较大, 同样规则翻倍起步, 考虑到低配设备, 还是不用了.

这个的确没有必要，TCP 的连接数很少，这类优化几乎不会带来体验提升。优化的方向应该是跑量时的零拷贝。

domainsExcluded 刚加的...所以他没有使用之前同样的判断规则吗?
fallbacks 可能确实要另外处理了.

这两个我来处理，你想一下还有哪些地方需要 strings.ToLower

其实严格来说，UDP 相关的很多代码也需要 strings.ToLower。。。涉及太广，先不动 UDP

也许 domainsExcluded 也应该可以用现在的匹配规则.一则统一,二则支持更多的配置方式.

也许 domainsExcluded 也应该可以用现在的匹配规则.一则统一,二则支持更多的配置方式.

特殊需求，暂时先保持简单吧，不过之后所有这种匹配的肯定要统一一下实现

也许 domainsExcluded 也应该可以用现在的匹配规则.一则统一,二则支持更多的配置方式.

特殊需求，暂时先保持简单吧，不过之后所有这种匹配的肯定要统一一下实现

OK. 其他的再想想....