Add the ability to specify a separate port when adding clients (xtls-reality)

[Pro100x3mal]

Hello. I have configured xtls-reality (manually) such that the server itself listens on 127.0.0.1:8443. On vps, using the nginx module ssl_preread_server_name, I configured it so that nginx listens on port 443 and then proxies to the services I need - xray on port 8443, other sites - on 4430, 4431, etc. In this case, port 8443 is closed using ufw. All of this can be customized using your excellent x-ui panel. But there is a need to manually adjust the URL links for clients, namely:

1) With this configuration, clients must connect to the xray server not at 127.0.0.1 (localhost), but at the vps IP address. You can solve the problem either by specifying a domain in the x-ui configuration that refers to the vps IP address or manually specifying the vps server IP in the client application instead of the automatically transmitted value 127.0.0.1.

2) With this configuration, x-ui creates a link for the client indicating port 8443 (for the reality protocol), but you need to manually set the client application to port 443. Hence the question: is it possible to add to the x-ui configuration the ability to specify the port separately in the settings client? To simplify this, is it possible to add the default value from the port server to this field, but give the opportunity to change it to another?

My use case is also relevant for setting up a very useful configuration with your dest like here: https://github.com/chika0801/Xray-examples/tree/main/VLESS-XTLS-uTLS-REALITY/steal_oneself

[X-Oracle]

1. With this configuration, clients must connect to the xray server not at 127.0.0.1 (localhost), but at the vps IP address. You can solve the problem either by specifying a domain in the x-ui configuration that refers to the vps IP address or manually specifying the vps server IP in the client application instead of the automatically transmitted value 127.0.0.1.

you want a new field to set custom port for user's client port rather than xray-server listen port? (like https://github.com/alireza0/x-ui/issues/610)

2. With this configuration, x-ui creates a link for the client indicating port 8443 (for the reality protocol), but you need to manually set the client application to port 443. Hence the question: is it possible to add to the x-ui configuration the ability to specify the port separately in the settings client? To simplify this, is it possible to add the default value from the port server to this field, but give the opportunity to change it to another?

this already exists with the name multi-domain but it only enables when tls toggle is enabled. it could be useful for non tls configs ( Vmess CDN, multi-domain configs ) too, so I suggest moving multi-domain right bellow listen field and make it available for all domains.

@alireza0, what do you think about this?

[Pro100x3mal]

@X-Oracle Ideally, it would be an excellent solution if two new parameters appeared when adding clients: listen ip and port (for url and subscriptions)

[X-Oracle]

@Pro100x3mal

for port, it is not possible to make deffrent ports for each inbound-user simce x-ray doesn't allow us to configure individual port for each use.

As for domain, it can be configured to be user based since it is not related to xray, but it makes the panel.

I personally think it can be implanted like this:

1- Have multi-domain available for all kind of configs in inbound section. ( this can easily implanted as it needs some adjustment to existing code.)

2- Have a new field in user section, if field the inbound section ignored and make config based on the user field. ( i think this can make panel heavier as it needs to check for each user and makes panel slower like a turtle if the users are a lot.)

[AliBelali]

recently I saw in a response alireza was considering add this option option that just change client's config link and qr code but config actually work in port that configed in inbound, this option is usefull for who is using reverse proxy like nginx

alternatively you can run nginx on custom port (let's asuume port 8443) and config x-ui inbound port that you want client's to connect (let's assume 443) after that add a firewall dst-nat rule to redirect all requests from network interface of server (for example eth0) on port 443 to port 8443 this rule in iptables is something like:

iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443

in this situation client send requests to port 443 firewall of the server redirects requests to port 8443 that is the port nginx is listening , nginx checks the request if request have format of v2ray connection it sends requests to port 443 (port that xray is listening)

for better security you can drop direct requests to nginx by adding another firewall rule:

iptables -A INPUT -m addrtype --dst-type LOCAL -i eth0 -p tcp -m tcp --dport 8443 -m state --state NEW -j DROP

[Pro100x3mal]

@AliBelali Yes, we'll be waiting for the author to implement this great feature! Your use case does not suit me, since I also have a variety of services on different ports, including through nginx

[AliBelali]

@AliBelali Yes, we'll be waiting for the author to implement this great feature! Your use case does not suit me, since I also have a variety of services on different ports, including through nginx

in this scenario since all requests on port 443 will be redirected to nginx(with firewall) , it's as same as running nginx on port 443 and for example if you have a website that handled by nginx it will be accessable on port 443

[alireza0]

Dear @Pro100x3mal @AliBelali @X-Oracle

As I mentioned in #607 and #610 , it is not sane to add a feature (for some group of users) which may cause problem or difficulty for normal users.

Adding this feature for subscription is somehow a logical idea. But for individual inbounds or the panel, I did not find a conclusion or a general way.

@X-Oracle Multidomain is designed for TLS based configurations which people can use SNI. This feature could be combined with sub+Fallback and avoid a lot of repeated work on links. BTW, It is already added to tls configuration in database. Therefore, moving it to a place in inbound table will cause problem for old configurations.

[X-Oracle]

@alireza0 could we at least make vmess to have a domain other than x-ui panel domain. from what i see, it can only be changed if listen Ip changes but if I for example put Cloudflare Ip in it, then xray won't listen to 0.0.0.0 and make the config unusable.

Multidomain is designed for TLS based configurations which people can use SNI. This feature could be combined with sub+Fallback and avoid a lot of repeated work on links.

I understand this. this is one of the benefits of Multidomain, but other non-tls could have benefits other than this. like:

• providing multiple domains in case one of them goes down.

BTW it is only a suggestion. Multidomain is a good feature for non-tls domains too.

[X-Oracle]

there is a lot of config combinations we could do in Xray-core since its core components are like a lego bricks.

I love x-ui because of its user management system but the inbound settings are limited to common Xray config examples. (Which is fine in most cases.)

I once though there could be a custom inbound in adding inbound section where we put xray inbound Json in it and let x-ui handle users by pointing to user key. but it seems a lot of work and maybe impossible since the backend seems limiting this functionality a lot.

any way thanks for your attention on this topic

Good Luck.

[alireza0]

The best possible movement is to add moltidomain for inbound and mark tls multidomain as depricated in next versions!

[X-Oracle]

The best possible movement is to add moltidomain for inbound and mark tls multidomain as depricated in next versions!

If you plan to implant this feature,then this is the best approach.

If you don't plan on database structure update then this is solution is what I think would work :

We could make it to read domain's data from a new field and set multi-domain base on that. if the filed returned null then read from old field and set multi-domain base on that. if old field returned null too, then multi domain is disabled.

On editing new multi-domain, update new filed and make old field null.

We could also update both to make panel migratable to old veraions, then in further version where we stablize the feature,we depricated feature on web panel and only read and update the new filed.

These are my opinion on this.

Good Luck.

[alireza0]

I have finished implementing my general idea on my new codes and tests. It would be appreciated if you can also test it in order to preparing for new release.

This implementation's benefits:

• Non-tls inbounds is now could have one or more domains!
• Support forcedTLS/none/same security for using on behind of proxy
• Change port is possible for each definition
• Moving to root of streamSettings instead of only tlsStream object
• Add a migration procedure for old MultiDomain users and optimizing database

[X-Oracle]

@alireza0 Awesome. I will test it once I learn how to build it 😅(I'm a python guy, I don't know how to build another language right now)

[alireza0]

Done! Under the test for new version...

[MK0ltra]

Completely unnecessary feature. Such complicity is against the general use of xui panels specially for normal users. There should be a limitation on requesting features in production purpose.

[alireza0]

@MK0ltra I am completely disagree! Limitation is useful for business. While multi domain and multi port is necessary for bypassing GFW and limitation.

[X-Oracle]

Completely unnecessary feature. Such complicity is against the general use of xui panels specially for normal users. There should be a limitation on requesting features in production purpose.

Right now, gfw is going easy on us but we don't know the methods they use for detecting us proxy providers.

What we can do is to make server's traffic more like normal browsing, so using 80 and 443 port is the only way and we can achieve that by multi port and nginx or haproxy fronting.

Definitely it makes more complexity but thanks to @alireza0 methods of implanting these, it won't effect users who don't understand and don't want to use these features.

[Enkidu-6]

I agree. The best way to blend in is to make our connections as similar as possible to normal web browsing, which means coming in through port 443 or 80 for everything. The current modifications by @alireza0 is a leap forward toward that direction.

Unfortunately I don't see a good A to Z instruction for implementing this method in x-ui with Haproxy or nginx, at least not in English. There may be something in Farsi somewhere which I'm not aware of. But as I said, this is a leap forward in that direction and hopefully soon we'll see a good instruction so everyone - novice or expert - can easily implement this.

This will also open the door to perhaps bundling x-ui with a preconfigured Haproxy or Nginx docker image to make it possible for everyone to use this method without having to modify the core X-ui panel with all the complexities that it entails.

Kudos to @alireza0 and Cheers.

[Pro100x3mal]

@alireza0

Thanks for your work! Great update to your service! I managed to do the following in x-ui:

1. Hide behind Nginx reverse proxy x-ui Web Panel and Subscription service. Services run on the same subdomain (xui.mydomain.com - web panel, xui.mydomain.com/sub/ - Subscription service). My settigs:

Domain for x-ui panel and subscription: xui.mydomain.com

x-ui Panel settings: Panel Listening IP: 127.0.0.1 Panel Listening Domain: - Panel Port: 5000

Subscription settings: Listening IP: 127.0.0.1 Listening Domain: - Subscription Port: 5001 Subscription URL Root Path: /sub/ Reverse Proxy URI: https://xui.mydomain.com/sub/

My Nginx conf for xui.mydomain.com:

server_name xui.mydomain.com www.xui.mydomain.com;
...
listen 127.0.0.1:4431 ssl proxy_protocol;
http2 on;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
...
location / {
#
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
...
location /sub/ {
#
proxy_pass http://localhost:5001;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
#
}
...

2. As a camouflage site for the Reality protocol, I use my own site running on the same server along with x-ui (camouflage.mydomain.com). My nginx config for this:

   server_name camouflage.mydomain.com www.camouflage.mydomain.com;
   ...
   listen 127.0.0.1:4430 ssl proxy_protocol;
   http2 on;
   set_real_ip_from 127.0.0.1;
   real_ip_header proxy_protocol;
   ...

3. To work correctly on the same port 443 of different services (the Reality protocol, my own camouflage site and a proxy for the x-ui and Subscription web panel), I use nginx with the ssl_preread module. My nginx stream conf:

map $ssl_preread_server_name $sni_name {
camouflage.mydomain.com xray;
xui.mydomain.com xui;
www.xui.mydomain.com xui;
default xray;
}
#
upstream xray {
server 127.0.0.1:8443;
}
#
upstream xui {
server 127.0.0.1:4431;
}
#
server {
listen 443 reuseport;
proxy_pass $sni_name;
ssl_preread on;
proxy_protocol on;
}

4. Based on №4, xray with Reality Protocol on my server can be run on a port other than 443. I ran it on 127.0.0.1:8443. I changed the site under which the Reality protocol is disguised in Settings-Inbounds: Dest: 127.0.0.1:4430 Server Names: camouflage.mydomain.com

Also, for correct URL links for clients, I configured External Proxy in Reality Settings: Host: camouflage.mydomain.com Port: 443 Xver: 1

As a result, all services work correctly on one external port 443. URL links for clients have the correct external port (443), while the xray server runs on internal port 8443. The Subscription service also works correctly on the same domain as the web panel and returns the correct URLs for clients.

Thanks again, everything works!

PS: if I made a mistake somewhere or misunderstood the meaning of the settings, please correct me