alireza0:TUIC 通配符证书测试通过,建议使用具体 SNI 或域名连接

在 Nexora-VPN/panel issue #7 中,alireza0 说明 0.0.6 服务端使用完整链的通配符证书 `*.example.com` 测试正常,问题更可能出在客户端收到的配置;他要求补充证书放置位置、SNI、节点地址类型、客户端版本和错误日志,并建议将 TLS `server_name` 设为匹配通配符的具体子域名、用域名作为节点地址后重新导入。其测试中这样设置可使 TUIC 连接成功。

作者原文

Hi, thanks for the report.

We tested TUIC with a wildcard certificate on 0.0.6 (full chain, *.example.com). The server side accepted the certificate and served it correctly, so the certificate itself is most likely fine. What probably goes wrong is what the client is told about it. We could make TUIC fail in one setup, but we need to know exactly what you did to be sure it is the same problem.

Could you tell us:

  1. Where did you put the certificate?
  • ☐ in Certificates (the panel certificate store) and selected it on the inbound
  • ☐ pasted directly into the inbound's TLS certificate / key fields
  • ☐ as file paths on the node (certificate_path / key_path)
  • ☐ as the node's certificate (Nodes → certificate)
  1. What is in the inbound's TLS server_name (SNI) field? Is it empty, or a concrete name like vpn.example.com?
  2. Is the node's address (or Link Address) an IP or a domain?
  3. Which client app and version (v2rayN, NekoBox, Hiddify, Shadowrocket, Clash/mihomo, …), and did you import a tuic:// link or a subscription (which format)?
  4. The client's error message or log, even one line. Please remove the UUID/password.
  5. (Optional) the TUIC link or the TUIC part of the subscription, with the UUID, password and IP masked. We mainly need the sni=, pcs= and insecure= parameters.

Something to try meanwhile

Set the inbound's TLS server_name to a concrete subdomain covered by your wildcard (e.g. vpn.example.com, not *.example.com), save, and re-import the link/subscription. In our tests, that made TUIC connect in every case. Using a domain instead of an IP as the node's link address has the same effect.

Let us know if that changes anything.