[BUG] Sing-box 订阅下发的部分节点配置不正确

[rapidacc]

Environment 环境

OS: Debian 12 HTTPS enabled: yes PHP version: 8.2.10 DB version: 10.11.6 Redis version: 7.2.4 Commit: 23fd45326f9b97e4962afd9be592cda1b6960ef0

Bug Info

以 tcp+http 为例，当前 SSPanel 会下发以下节点配置

{
      "type": "vmess",
      "tag": "node name",
      "server": "node.ip",
      "server_port": 12345,
      "uuid": "d4e67c35-2241-4880-bfe7-198421e41112",
      "security": "auto",
      "alter_id": 0,
      "tls": {
        "server_name": "www.baidu.com"
      },
      "transport": {
        "path": "/",
        "headers": {
          "Host": [
            "www.baidu.com"
          ]
        }
      }

这是不正确的，无法被 Sing-box 客户端接受。 首先 tcp+http 不需要配置 tls 部分。其次，在 transport 部分中应该定义 "type": "http"。

根据 Sing-box 文档，正确配置应该为

{
      "type": "vmess",
      "tag": "node name",
      "server": "node.ip",
      "server_port": 12345,
      "uuid": "d4e67c35-2241-4880-bfe7-198421e41112",
      "security": "auto",
      "alter_id": 0,
      "tls": {},
      "transport": {
        "type": "http",
        "path": "/",
        "headers": {
          "Host": [
            "www.baidu.com"
          ]
        }
      }

[AutisticShark]

首先 tcp+http 不需要配置 tls 部分

Maybe ask sing-box for a more robust config parse system that can

1. Behave correctly when using the default value
2. Won't explode because there is empty value in the config

Then we can talk about proper sub support for singbox, I ain't gonna add a shit ton of if statements in the code just because their core doesn't understand what ignore empty value means.

在 transport 部分中应该定义 "type": "http"

Is that hard to experiment with the network section of the custom config before opening a useless bug report?

[rapidacc]

Is that hard to experiment with the network section of the custom config before opening a useless bug report?

I noticed that the tcp+http examples section of the SSPanel Wiki made an update a few days ago, changing the original "network": "tcp" to "network": "http". This allows Singbox subscriptions to work properly. However, this will make the backend unconnected. According to V2Ray and Xray documentation, there is no Stream Transport Protocol called "http". tcp+http just adds the "header" config. "network": "tcp" is the correct one.

[AutisticShark]

Sounds like a V2Ray/Xray core problem to me. All V2Ray transport including httpupgrade all have a dedicated transport name, but the http transport does not, what a brain-dead design. Not to mention that all other proxy cores treat http as a standalone transport type.