使用ws.okx.com为sni无法使用

[ayanami-desu]

这个域名来自某平台的api文档wss://ws.okx.com:8443，用这个域名作sni的话，服务器就可以不监听443端口。实际使用中报错如下

服务端配置：

    image: ghcr.io/ihciah/shadow-tls:latest
    restart: always
    network_mode: "host"
    security_opt:
      - seccomp:unconfined
    environment:
      - MODE=server
      - LISTEN=0.0.0.0:8443
      - SERVER=127.0.0.1:16520
      #- TLS=www.apple.com.cn;dl.google.com;cloudflare.com
      - TLS=ws.okx.com:8443;wsaws.okx.com:8443;wspap.okx.com:8443
      - PASSWORD=password
      - V3=1
      - STRICT=1
      - ALPN=h2;http/1.1
      #- RUST_LOG=error

客户端配置

services:
  shadow-tls:
    image: ghcr.nju.edu.cn/ihciah/shadow-tls:latest
    restart: always
    network_mode: "host"
    security_opt:
      - seccomp:unconfined
    environment:
      - MODE=client
      - LISTEN=0.0.0.0:3444
      - SERVER=myserver:8443
      #- TLS=www.apple.com.cn;dl.google.com;cloudflare.com
      - TLS=ws.okx.com;wsaws.okx.com;wspap.okx.com
      - PASSWORD=password
      - STRICT=1
      - V3=1
      #- RUST_LOG=error

[ihciah]

你开启了 V3 Strict，并且使用的域名没有全部支持 TLS1.3。 我这边确认了下，三个域名里只有 ws.okx.com 支持 TLS1.3(openssl s_client -tls1_3 -connect ws.okx.com:8443)，仅使用 ws.okx.com 是可以在 Strict 模式下工作的。

使用非标准端口的 TLS 服务非常少，记录这个对中间人来讲意义不大。所以几个解决方案：

1. 你使用 443 配合 8443 的服务，或者使用 8443 配合 443 的服务应该都是 ok 的。
2. 如果你是因为 443 端口被占用，那么可以利用 shadow-tls 的 SNI Proxy 功能让流量代理到本机的 nginx 等其他服务。这样应该有大量的域名符合需求。
3. 保持现有配置，删除另外两个域名。
4. 关闭 Strict 模式。

[ayanami-desu]

我后续测了一下，发现这三个域名都在移动的sni阻断名单里 所以不是wss的原因，和程序的关系应该不大？

[ayanami-desu]

可以利用 shadow-tls 的 SNI Proxy 功能让流量代理到本机的 nginx 等其他服务

关于这一点，假设我现在只填写了一个sni：cloudflare.com，能否支持将除此sni的流量全部导向nginx/其他应用？ 在服务器上运行了多个网站时就不用写太多的配置了

[ihciah]

所以不是wss的原因，和程序的关系应该不大？

我用 ws.okx.com 测试是过的（客户端只指定这一个域名，开 strict）。但是另外两个不支持 TLS1.3，所以开 strict 一定会报客户端认证失败，就是你截图里的状态。

在服务器上运行了多个网站时就不用写太多的配置了

shadow-tls 服务端会根据入流量中携带的 SNI 尝试查询配置的 mapping（域名->addr）。如果没有查找到，就会使用 fallback 地址。将 fallback 地址填成你的本机 nginx 就好。配置中的最后一条会被作为 fallback 使用。