分享DOH 本地模式 (DOHL)发送dns请求使用utls指纹的配置

[intmain0]

#4313
最新的xray支持DOHL使用utls指纹了，但是需要使用h2c+Freedom TLS，比较复杂。花了点时间研究了一下配置，分享给有需要的人。
关键的部分就是dns、outbounds、routing三大块，其它部分就省略了

{
  "dns": {
    "servers": ["h2c://dns.google/dns-query"],
    "tag": "dns-query"//tag需要和routing的一致
  },
  
  "inbounds": [
    {
//省略
    }
  ],
  "outbounds": [
    {
      "tag": "tls-repack",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "ForceIP"
      },                               
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "fingerprint": "chrome",
          "serverName": "dns.google",
          "verifyPeerCertInNames": ["fromMitM"],              
          "alpn": ["fromMitM"]
        }
      }
    }    
  ],

  "routing": {
    "domainStrategy": "AsIs",
    "rules": [                      
      {
        "outboundTag": "tls-repack",
        "domain": ["dns.google"],//不加的话如果有其它dns服务器流量也会被重定向到tls-repack
        "inboundTag": ["dns-query"]//不加的话浏览器访问不了dns.google  
      }
    ]
  }
}

[RPRX]

其实也不是不可以做成 DoH local 默认用 Chrome 指纹，不过那样的话就是默认 h2 了，现在是默认 h1 但能 upgrade

[RPRX]

我看了下 http2.Transport 的配置没有什么能改 window_update 发送速率的地方，看来还得是 Browser Dialer

Browser Dialer 理论上也能支持 stream-up，只是会麻烦一些

[intmain0]

我看了下 http2.Transport 的配置没有什么能改 window_update 发送速率的地方，看来还得是 Browser Dialer

Browser Dialer 理论上也能支持 stream-up，只是会麻烦一些

https://github.com/golang/net/blob/55989e24b972a90ab99308fdc7ea1fb58a96fef1/http2/transport.go#L899
这里是控制window size
https://github.com/golang/net/blob/55989e24b972a90ab99308fdc7ea1fb58a96fef1/http2/flow.go#L11
flow.go里已经写死了最小更新窗口为4<<10(4096)

[intmain0]

http2.Transport里能配置的只有window size。window_update发送速率和更新窗口大小有关，这个没法直接配置得改http2库吧？

就算降低了window_update发送速率（把更新窗口调大），window_update帧的包长特征仍然存在。我就在想为什么有的单个tcp包里有多个http2帧，能不能让多个window_update在同一个tcp包里就能解决包长特征了。我试了一下发现是因为发送一帧还需要执行cc.bw.Flush()刷新缓冲区，刷新缓冲区前在缓冲区堆积的帧就会在同一个包里，例如 https://github.com/golang/net/blob/master/http2/transport.go#L896-L900
还有人提出让header和data帧合并发送 golang/go#58674 ，如果真能实现的话就不需要header padding了

要不要新开一个discussion讨论一下http2库的特征问题？感觉一直在这个问题底下聊不太合适。现在看起来这些问题和xhttp没啥关系，都是http2库的锅，但是放着不管好像也不好，毕竟都用utls都模拟成浏览器了@RPRX

[RPRX]

其实有一个曲线救国方案，就是在 h2c 外面套个函数去解析它的帧，把多余的 window_update 帧删掉，还有合并 header 和 data

Golang h2 client 的 header 和 data 没粘一起是有点怪，我还以为是粘一起的，因为 h2 server 是必须手动 flush 除非 return

不过要不要粘一起还是得看 Chrome 的行为，此外调用 h2 和 tls 库均会导致 data 被重复 copy，这也是需要优化的点

[intmain0]

其实有一个曲线救国方案，就是在 h2c 外面套个函数去解析它的帧，把多余的 window_update 帧删掉，还有合并 header 和 data

Golang h2 client 的 header 和 data 没粘一起是有点怪，我还以为是粘一起的，因为 h2 server 是必须手动 flush 除非 return

不过要不要粘一起还是得看 Chrome 的行为，此外调用 h2 和 tls 库均会导致 data 被重复 copy，这也是需要优化的点

其实不需要太关注chrome的行为，包复用+外层tls一裹，里面啥都看不到。
现在的问题是包长特征不止一处，可以应用在给ip打分上，满足几个特征+vps IP段直接阻断