MapleCool

我的理解，你应该是想加个访问者IP判断的功能，如果访问IP来自你的手机IP，则强制修改ECS为你手机公网IP子网段。 给你提供一种临时的解决思路，使用不同的端口创建两个不同的main_sequence， 例如main_sequence_a和main_sequence_b 其中一个main_sequence_b的全部ECS判定，子网IP设置为你的手机IP段 手机去访问main_sequence_b的端口，应该可以解决你的问题

> > 我的理解，你应该是想加个访问者IP判断的功能，如果访问IP来自你的手机IP，则强制修改ECS为你手机公网IP子网段。 给你提供一种临时的解决思路，使用不同的端口创建两个不同的main_sequence， 例如main_sequence_a和main_sequence_b 其中一个main_sequence_b的全部ECS判定，子网IP设置为你的手机IP段 手机去访问main_sequence_b的端口，应该可以解决你的问题 > > @pmkol 判断访问者可以通过query_matcher插件的client_ip功能实现，因为手机VPN模式下访问内网DNS时client ip是固定的。 > > 我需要解决的问题是手机漫游到不同的网络(4G或WIFI), 访问国内的CDN网站时，由于DNS是内网modns解析的，CDN不是最优的。需要使用mosdns的ecs插件ipv4字段能动态设置上不同网络(4G或WIFI)的出口公网IP或subnet. 目前ecs插件的ipv4地址是事先配置好固定的。 用上面的方法，建立两个不同的main_sequence，把其中一个设置为你手机专用的，即所有ECS都是你手机的子网IP，这样不能解决么？

遇到类似的TFO问题，centos8内核已开启TFO，服务端程序开启了tcp_fast_open参数，用nginx反代，且在nginx的listen后面已经加上了fastopen=256，但实际抓包发现并没有附带TFO的cookie

> net.ipv4.tcp_fastopen = 3 参数是开启的，且通过命令已验证该数值为3生效， 我使用的是trojan协议而非shadowsocks，配置中我有关闭sing-box的tls加密，使用nignx作为前端进行tls加密，并使用了h2协议 我的客户端并非是windows，而是是路由器使用了xray并开启了fastopen选项，为了验证这个问题，我又使用了IOS系统上的shadowrocket客户端，并开启了fastopen，但通过抓包发现TFO依旧没有生效

您捕获的 SYN 数据包中，并没有存在 cookie 请求选项 后面的3个问题，我暂时无法给出回应，后续有时间精力测试后可以给出反馈。 目前我已经关闭了TFO选项，因为使用H2方式连接，TFO是否开启影响并不大。 提一个问题，"tcp_fast_open": true,这个参数，是否只是针对监听客户端的，或者说这个参数是不是只生效在客户端与sing-box服务端连接的过程中？ 当开启TFO后，如果客户端与sing-box服务端没有使用TFO连接，sing-box连接网站时，是否还带有TFO特性呢？

同样问题，发现并没有生效，使用的是trojan协议

https://github.com/pmkol/easymosdns/tree/rules 可以试试我新做的库，上面的库有污染IP

> ngninx1.25是属于开发版本, 你可以了解下, nginx 的奇数版本都是开发版本, 只有偶数版本才是正式稳定版本, nginx的历史版本下载页面你会发现全是偶数版本 > 1、Mainline version并非开发版，只是一些中文媒体的错误叫法被延续至今，真正的开发版位于：https://hg.nginx.org/nginx/ 2、由于更新Nginx的频率较低，所以为了获得最新的Nginx特性，Tengine、OpenResty这些分支版本，会使用Mainline version迭代3~4个小版本后的版本，可以查看一下历史代码： https://github.com/alibaba/tengine/tree/master/src/core https://github.com/openresty/openresty/tree/nginx-1.25.3 3、建议及时更新1.25版本，是因为这个版本原生对http3支持，而目前tengine只能使用tongsuo来支持http3，但tongsuo不支持ktls，会导致http2/1.1享受不到ktls的加成，阿里自己的业务环境由于使用硬件级的异步SSL方案，而无需使用内核级的KTLS方案，所以KTLS这里一直没及时跟进，这才是提建议的原因

> Hello. > > I see that this patch is very similar to this one: https://mailman.nginx.org/pipermail/nginx-devel/2020-June/013211.html Is it the same patch or maybe you are an author? > > AFAIK,...