• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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