Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VMESS Websocket TLS timeout with high load #1062

Open
majidsadr opened this issue Jun 28, 2024 · 4 comments
Open

VMESS Websocket TLS timeout with high load #1062

majidsadr opened this issue Jun 28, 2024 · 4 comments
Labels
T: Bug Something isn't working

Comments

@majidsadr
Copy link

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.
image

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"
      }
    ]
  }
}
    ```
@majidsadr majidsadr added the T: Bug Something isn't working label Jun 28, 2024
@M03ED
Copy link
Collaborator

M03ED commented Jun 29, 2024

try xray 1.8.4 and check same thing happen or not

@majidsadr
Copy link
Author

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

@SaintShit
Copy link
Contributor

SaintShit commented Jul 5, 2024

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
Copy link
Author

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 https://0.0.0.0:8000 (Press CTRL+C to quit)
marzban-1 exited with code 137

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants