• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Same subdomain, Different Ports lead to different applications

lukegalea16

New Pleskian
For the same subdomain, for example sub.example.com is it possible to route requests on port 5683 to a Node JS application and requests on port 80 to a PHP/Laravel application?
I aim at having incoming data on port 5683 and save to a DB whilst serving incoming API requests on port 80. I believe it can be done using Nginx but I am not sure how.
 
You could even have incoming data reverted to another service on the same port.
The least intrusive way is to work with an added config file in the folder /etc/nginx/conf.d

The config files in that folder are parsed by Nginx in alphabetical order.
The file zz010_psa_nginx.conf is responsible for all the websites that are managed by Plesk.

If you create a <file>.conf which is alphabetically lower than zz010_psa_nginx.conf it will be parsed before and if it's higher it will be parsed after all the websites that are managed by Plesk.

Nginx is quite powerful as a router of http (it can even do more than http).
In most configurations it will be in front of Apache and will forward the http to that service.
Mostly it is looking for the host name, but you can trigger on almost anything, the URL (what comes after the hostname), the source IP, headers.
It can use regular expressions as well.

But lets keep it simple.
You want to let nginx listen on another port than 80 and 443 and then redirect that to another service.
I would let that service listen on 127.0.0.1 so it is not accessible from outside and you could let nginx listen on that same port, let it trigger on that subdomain and forward it to 127.0.0.1

I don't want to do everything for you and just give you one of my own config files as an example.
It's doing something else. It's a web-service that's only doing http (no https) and is running on alternate port which I don't want to access directly. I don't want to use a portnumber either.

The service is syncthing and its webif is running op 127.0.0.1 on port 8384
I can access that service thanks to nginx on ( by using the directive server_name syncthing.wolf.com;)
I don't have to open the firewall to 8384 now and no-one will be speaking to that service directly.
On top of that it does not need to manage the wildcard-certificate which is handled by nginx.


You don't even have to restart nginx to get the changes in effect. Just create that file and do a "killall -HUP nginx".
If your configs are invalid then nginx will reject them and everything keeps working as it was.
If you rename the file to <file>.conf.disabled the file will not be parsed either. Only files that end with .conf will be parsed.

with the command "nginx -T" you can see the complete config with all the includes. The command "nginx -t" can be used to test the config without trying to run it.

# cat /etc/nginx/conf.d/zz090_syncthing.conf
server {
listen 80.21.122.40:80;
server_name syncthing.wolf.com;

error_log /var/log/nginx/ownservices/error.log;
access_log /var/log/nginx/ownservices/access.log combined;

return 301 https://$host$request_uri;
}

server {
listen 80.21.122.40:443 ssl http2;
server_name syncthing.wolf.com;

error_log /var/log/nginx/ownservices/error.log;
access_log /var/log/nginx/ownservices/access.log combined;

ssl_certificate /root/.ssh/wildcard.wolf.com.pem;
ssl_certificate_key /root/.ssh/wildcard.wolf.com.key;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security $hsts_isd_header always;
#add_header Content-Security-Policy "default-src 'self';" always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options nosniff always;

ssl_dhparam /etc/dhparam/dhparam4096.pem;
ssl_session_timeout 5m;

ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

client_max_body_size 128m;

location / {
proxy_pass http://127.0.0.1:8384;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
 
You don't even have to restart nginx to get the changes in effect. Just create that file and do a "killall -HUP nginx".
... or use "nginx -s reload", which does the same but is less dangerous than killall in case of typo and/or brainfart.
 
Can you please take a look at this thread (also related to ports)
 
Back
Top