New answers tagged

0

A different solution that may work for others: use the .pem file for both ssl_certificate and ssl_certificate_key That is: ... ssl on; ssl_certificate conf.d/cert.pem; ssl_certificate_key conf.d/cert.pem; ...


0

That's because nginx can't do that. It can terminate an SSL connection, but it cannot pass one through. You have at least two options: Stick the SSL certificates in a tiny Docker volume that's shared between your letsencrypt container and your nginx container. While you're at it, you may as well let nginx intercept Let's Encrypt challenges as well, which ...


1

If nginx is running, but cannot connect to its upstream server, e.g., to tomcat, then you'd be getting a 50x-style error, NOT a connection refused one. Browser reports site refused to connect. ERR_CONNECTION_REFUSED – Chethan S. Apr 21 at 15:34 This means that you cannot connect to nginx in the first place. Are you sure it is running? Best way to ...


0

facepalm It turns out that I was missing a trailing slash on my ProxyPass directive: ProxyPass "/site/" "balancer://cms" should have been: ProxyPass "/site/" "balancer://cms/" (Note the trailing slash before the close-quote.) That literally fixed everything. I'm happy to delete this question and answer if folks want to close it as "simple ...


0

We pass in the upstream addr as a separate header like this server { listen 80; server_name example.com; location / { proxy_pass http://main; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; add_header X-Upstream $upstream_addr; } } What if you tried? server { listen 80; ...


1

http{ ... server { listen 80; server_name api.example.com; #charset koi8-r; access_log logs/api.example.com.access.log combined; location / { proxy_set_header X-Real-IP $remote_addr; proxy_pass http://servername1; root path1; } } server { listen 80; server_name ...


3

Your two server blocks will always conflict such that the first observed server block in the configuration file will be taking precedent as the default server block for all requests, unless you specify a proper server_name for each config to apply to incoming requests for that hostname / subdomain. (This applies also for all requests of which a requested ...


1

Or you simply assign a fixed port in the reserved port range and grant your application the rights to bind to that port. sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/application


0

If you have Selinux (not sure about AppArmor), you can most likely achieve this: Make sure that only the context of that specific application can listen to that port and then make sure that only your desired user can start that application.


0

Put the logos in different folders named like your domain, like ".../domain1.com/images", ".../domain2.com/images/". Inside these you put the respective logos all named logo.png Add another location to your server blocks: location /images/ { root /var/www/vhosts/domain1.com/httpdocs/$server_name/; } This should serve different logo.png files ...


0

You say port 80 to 10443, is your Docker install still serving HTTPS? If so, try to set both to HTTP and use a less confusing port 10080 on Docker.


1

Make sure your proxy from Nginx is going to "127.0.0.1" instead of your server's / site's hostname or IP. If this is done, you could have an issue with the Tomcat connector being on IPV4 (forced by 127.0.0.1) while Nginx is trying to get to it on the IPv6 stack.


0

No. Nginx is a web server and a reverse proxy, you need to deal with this at the application level. Edit - if you modify your requirements somewhat you may be able to get something working. Maps might be worth looking into, shared document roots. But as your requirements stand right now I can't see an easy way to do it. That's not to say it's impossible, ...


2

I would start with setting your nginx log to debug and then check to see where the request throws the 503 server { #other config error_log /var/logs/nginx/example.com.error.log debug; #other config }


1

For the purpose of the question I'll assume that the following IPs Nginx 192.168.0.1 Tomcat 192.168.0.2 Configure the tomcat server Change the following line address="127.0.0.1" to address="192.168.0.2" - This will tell Tomcat to listen on the local ip rather then the loopback address. Then we want to configure the IPtables. I used the generator ...


1

Don't expose the Tomcat server directly to the Internet. Put the web server into a DMZ (ie behind a firewall), then put the Tomcat server behind another firewall. You can use software firewalls provided by the operating system, or hardware firewalls, but you haven't said what OS you're using so I can't give more advice. Something like IPTables or Windows ...


1

The problem with what you're trying is that it you're treating the entire configuration as though it were constantly being parsed and interpreted at runtime, which of course is not the case. Certain arguments to the various directives are static, others dynamic, but server declarations are most definitely static. A server represents exactly one target ...


0

I think you just need to take care of location mapping. So here is fix for you server { listen 8080; access_log /var/log/nginx/server.access.log main; root /usr/share/nginx/htdocs; index index.html index.htm; location ~* ^/apps/ { rewrite ^/apps/(.*) /$1 break; proxy_pass http://our-amazon-s3-bucket/apps; } }


0

That is common issue for who want to work on sandbox envoriment. If i got your problem correctly, you are looking for wrong part of the system for solution. You need to change your cms paths. I think you can use environment variables maybe called root_path and then we can pass proxy value or something else at initial time to the container.


0

As using port other than 80 is not possible (unknown reason) the workaround involved using a subdomain & listening to ip-address:port. server { server_name subdomain.domain.com; listen IP-Address:80; location / { proxy_pass http://localhost:5601/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; ...


0

I think you should write your listen directives as follows: server { listen 80; server_name domain.com; location { ... } } server { listen 80; server_name subdomain.domain.com; location { ... } } Also, here's a great explanation on how Nginx selects which server block to use: ...



Top 50 recent answers are included