Alternative for clients storage

[torikki-tou]

Disclaimer: i don't speak Chinese so i may not know about similar discussion in Chinese

As far as i know Xray-core has only 2 ways to store clients for VLESS.

1. Config file – can't be changed without restart, become hard to read if has too much clients, hard to scale.
2. Managing clients by API calls – not persistent.

There is workaround if we combine 2 strategies (API call + file change) but it does not resolve 2 last problems with file storage.

My proposal is to allow alternative storages for clients. The ideal scenario is if i can store clients in Redis (or other DB) or integrate with third-party REST API and also have some in-memory cache for performance.

Inbound config can look like this:

{
  "inbounds": [
    {
      "protocol": "vless",
      "settings": {
      // Clients section is ignored if clientsStorage specified 
        "clients": [
          {
            "id": "4c3fe585-ac09-41df-b284-70d3fbe18884",
            "email": "user1@myserver",
            "flow": "xtls-rprx-vision"
          }
        ],
        // Storage config
        "clientsStorage" : {
          // Required Enum field with storage type
          "type": "redis",
          // Required field with custom setting for choosen storage type 
          "settings": {
            // Some Redis settings
            "connectionString": "redis:6379",
            "prefix": "xray",
            "delimiter" : ":",
            // Let's say our storage supports cache
            "cache": {
              "ttl": "5m",
              "maxSize": 100
            },
            // Default flow for clients in storage
            "defaultFlow": "xtls-rprx-vision"
          }
        },
        "decryption": "none"
      }
    }
  ]
}

To implement this Validator must become an interface, custom storages must be written and we need to change config scheme. It is a perfect place to use plugins to let people write their own storages, but i find it too hard to implement, while things i described i can make myself.

My questions:

1. Do you accept that problem with clients configs exists?
2. Do you like my solution? Do you see problems or ways to make it better?

[mmmray]

If you want advanced client management, I suggest to look into Marzban. I still agree that xray could have a different API for it (I quite like the one that Hysteria2 has, where it calls an HTTP endpoint to help with auth)

[torikki-tou]

I took a look at implementation and it is exactly what i was imaging, simple and straight forward. But HTTP call for each connection is not what i would call performant (comparing to sync.Map implementation in Xray). Cache is definitely needed.

At this point, when we even have such example i would ask @RPRX to take a look at this conversation

[mmmray]

So, the problem is what to do with the existing APIs. My impression is that core devs already think there are too many APIs and are tired of maintaining so many features (correct me if I'm wrong)

If there is a proposal to deprecate them, and agreement from the panel maintainers (Marzban, x-ui, etc), then it could be done. I think it is however unlikely that core devs will write the PR themselves, because mostly commercial VPN vendors need this feature. So somebody else would have to come up with a complete proposal for API changes, implement, port panels to new API, etc.

[torikki-tou]

I am going to implement this feature myself anyways, just want to hear from core devs if they want to include it into main project

Waiting

[donnyxray]

Did you have any luck implementing this?

[torikki-tou]

@donnyxray nah, i dropped that task mainly because of xray being to hard to change. but i have an idea to fork singbox vless lib and implement storage interface in it so it can be used with any storage you need.

[donnyxray]

I'm interested in this too, though for different reasons. Our config is quite large as we allow each user to have custom inbounds, outbounds and routing. Servers are starting to run out of memory.

The on-disk JSON is perhaps 20MB per process, but Xray-core blows this up into 2GB RAM usage easily. Run multiple processes and your RAM is full.

It feels wasteful. A given server at a given time serves only a handful of users. But it keeps thousands of other users in its memory unnecessarily.

Ideally it loads and caches the config for a particular user when this user actually connects. The drops the cached config if the user hasn't connected for a certain amount of time.

I'm not sure if it really needs Redis or a database. As noted, the actual JSON is quite small and can be processed very quickly. It just needs to gain the ability to re-read it and cherry-pick the users/routing/outbounds it actually needs.

[torikki-tou]

i believe "re-read it and cherry-pick the users/routing/outbounds it actually needs" is a complicated task, where "read from DB and cache" is rather simple