VMESS Websocket TLS timeout with high load

[majidsadr]

Describe the bug I faced an issue when using Marzban with this config: VMESS+WS+TLS and cloudflare SNI. the problem is when active users increase to about 70 per second, the specific config with high load response time increases too much till a timeout. But another config with another domain and SNI acts normal without any problem. I've set a monitoring up in server and saw TCP_alloc - Allocated sockets metric in Sockstat TCP chart is continuously increasing in this situation. I don't know if there is something that doesn't close WS connection or something else. This problem doesn't accrue in 3XUI by MHSanaei and the maximum amount of this metric goes to about 1.5k with similar load, But in Marzban I saw a 5k amount of this and going to have timeout for configs.

To Reproduce Steps to reproduce the behavior:

1. Create VMESS+WS+TLS+SNI configs
2. Have about 50~60 active users at the same time.

Expected Behavior Having issue when connecting to config.

Screenshots The spike is when users are active in server.

Machine details (please complete the following information):

• OS: ubuntu 20.22
  • Python version: 3.12.3

Additional Description This is my VMESS+WS+TLS config in Marzban:

    {
      "tag": "VMess Websocket TLS",
      "listen": "0.0.0.0",
      "port": 2053,
      "protocol": "vmess",
      "settings": {
        "clients": []
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "acceptProxyProtocol": false,
          "headers": {},
          "host": "",
          "path": "/ws"
        },
        "security": "tls",
        "tlsSettings": {
          "alpn": ["h2", "http/1.1"],
          "certificates": [
            {
              "certificateFile": "/var/lib/marzban/certs/example.com.lol.cer",
              "keyFile": "/var/lib/marzban/certs/example.com.cer.key",
              "ocspStapling": 3600
            }
          ],
          "minVersion": "1.2",
          "cipherSuites": "",
          "maxVersion": "1.3",
          "rejectUnknownSni": false,
          "serverName": ""
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    },

outbound and routing:

{

  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "ip": ["geoip:private"],
        "outboundTag": "blocked",
        "type": "field"
      },
      {
        "domain": ["geosite:private"],
        "outboundTag": "blocked",
        "type": "field"
      },
      {
        "protocol": ["bittorrent"],
        "outboundTag": "blocked",
        "type": "field"
      }
    ]
  }
}

[M03ED]

try xray 1.8.4 and check same thing happen or not

[majidsadr]

@M03ED the issue still happens. I've tried 1.8.4 and 1.8.11 (like @MHSanaei panel xray core version).

[SaintShit]

it's happening since 1.8.6 was released.

I downgraded Xray version and everythings ok

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install --version v1.8.4

    volumes:
      - /usr/local/bin/xray:/usr/local/bin/xray

is there any chance that you configured the core wrong?

[majidsadr]

I've done this before. To make sure, This my marzban logs after restarting service:

➜  marzban restart
[+] Running 1/1
 ✔ Container marzban-marzban-1  Removed                                                                                                                                      0.9s 
[+] Running 1/1
 ✔ Container marzban-marzban-1  Started                                                                                                                                      0.3s 
marzban-1  | INFO  [alembic.runtime.migration] Context impl MariaDBImpl.
marzban-1  | INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
marzban-1  | INFO:     Started server process [1]
marzban-1  | INFO:     Waiting for application startup.
marzban-1  | INFO:     Generating Xray core config
marzban-1  | INFO:     Xray core config generated in 0.08 seconds
marzban-1  | INFO:     Starting main Xray core
marzban-1  | WARNING:  Xray core 1.8.4 started
marzban-1  | INFO:     Starting nodes Xray core
marzban-1  | INFO:     Application startup complete.
marzban-1  | INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
marzban-1 exited with code 137