nginx proxy from 80 to 444 same IP - proxy

I have some webs that are served by nginx with SSL (443) without problems.
Now, I have the web mail serving SSL on port 444, but I want nginx to proxy from 80 to 444 when webmail.mydomain.com reaches.
I've tried some config but no one of them worked. This is the last one ...
thanks,
m.
server {
listen 80;
server_name webmail.mydomain.com;
root /etc/nginx/sites-available/webmail/;
access_log /etc/nginx/sites-available/nginx.log;
client_max_body_size 50M;
location / {
proxy_pass http://192.168.1.2:444/;
proxy_redirect https://192.168.1.2:444;
}
}

I'm doing something similar. What worked for me was to define an upstream server on the same box
upstream some_name {
server 127.0.0.1:4000;
}
and then doing
proxy pass http://some_name;
Obviously my ports are different

Related

Nginx Reverse Proxy For Web App Hosted on Local Server

I am hosting a web application via a home server. I have my Cloudflare DNS A record pointed to my public ip and my firewall is off. I am using cloud flare for SSL.
My app is running on local host (127.0.0.1) port 1624.
I am using nginx. My server name is my public ip and listen is port 80.
My reverse proxy is pointed at 127.0.0.1:1624.
I have port 80 open on my router as well.
For some reason I am not able to connect to my website. What could be causing this?
The developer of the web app has told me to use my domain name for the server name and keep the port as default 80 while pointing the reverse proxy to 127.0.0.1:1624.
My nginx conf:
server
{
server_name {mypublicip};
#server_name {mydomainname};
listen 80;
location / {
proxy_pass http://127.0.0.1:1624; # my web app proxy
proxy_http_version 1.1;
proxy_set_header Host $host:$server_port;
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;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
Router Settings:
I've tried:
Nginx conf -
server_name > domain NAME
server_name > public ip
My app is working when I go to 127.0.0.1:1624 just not my domain.
You should configure port forwarding on your router - so that all packets coming on port 80 of the public IP on your router will be forwarded to port 80 of your local PC (which probably has an internal IP address in a 192.168.xx.yy range). Then your nginX should listen on port 80 at that 192.168.xx.yy address on your PC and proxy_pass to 127.0.0.1:1624 where your application is listening.
IF you don't do this - packets will end up on the router instead of at nginX in your local PC.

Where the response is comming from - Nginx? App? Kubernetes? Other?

I have an app providing RESTFull api in google kubernetes cluster.
In front of application i have an nginx working as a proxy_pass.
The problem is that one request of few thousands (1000, 2000) has bad data in response (other users data). Analysing logs showed that request of the bad response doesn't come to the application at all.
But it comes to nginx:
2019/05/08 13:48:03 [warn] 5#5: *28350 delaying request, excess: 0.664, by zone "one", client: 10.240.0.23, server: myportal.com, request: "GET /api/myresource?testId=10 HTTP/1.1"
In the same time there's no logs in the app for testId=10 (but there are for testId=9 and testId=11 when i make sequential test 1..1000)
Nginx configuration is almost default
limit_req_zone $binary_remote_addr zone=one:10m rate=4r/s;
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name myportal.com;
if ($http_x_forwarded_proto = "http") {
return 308 https://$server_name;
}
charset utf-8;
access_log on;
server_tokens off;
location /api {
proxy_pass http://backend-service:8000;
limit_req zone=one burst=10;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
There is no caching configured (or maybe it's on by default?).
Application is working in google kubernetes environement, so the request chain looks like this
(k8s ingress, nginx-service) -> nginx -> (k8s backend-service) -> backend
Backend app is written in spring and using jetty to run.
Nginx version was updated from 1.13.X to 1.15.12 but both has the same issue.
I have no idea what and where should i check to find the cause of the problem.
Error you see comes from Nginx because of configs limit_req_zone $binary_remote_addr zone=one:10m rate=4r/s; and limit_req zone=one burst=10;
Read more here: http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
Did you put it for reason?

Multiple websites with one IP: settings with proxy server and proxy cache (flask, uwsgi, nginx)

I want to allow my nginx server to server multiple subdomains.
Each site is served by a flask + uwsgi, listening to own ports.
All sites have many endpoints with same name, and responses are cached in different zones: I want to serve the correct cache (or correct site) from the proxy server.
I read https://askubuntu.com/questions/766352/multiple-websites-on-nginx-one-ip : in my configuration I keep having domain2 redirected to domain1.
I cannot find proper configuration for listening to uwsgi and have the proxy server serve the correct site.
How to properly set the ports and proxy_cache on the proxy_server to allow nginx serve two flask sites from a single server?
Below is my set current setup:
configuration domain_1
server {
server_name www.domain1.com;
return 301 $scheme://domain1.com$request_uri;
}
server {
listen 8000 default_server;
server_name domain1.com;
root /var/www/example_site_1;
# common locations for all sites
location / {
include uwsgi_params;
uwsgi_pass unix:/var/www/example_site_1/domain1.sock;
}
# API
location /api {
include uwsgi_params;
uwsgi_param UWSGI_SCRIPT wsgi;
uwsgi_pass unix:/var/www/example_site_1/domain1.sock;
}
}
# Set cache directory for site
proxy_cache_path /tmp/nginx/domain1 levels=1:2 keys_zone=my_zone_domain_1:10m max_size=50m inactive=60m;
proxy_cache_key "$scheme$request_method$host$request_uri";
# Virtualhost/server configuration
server {
listen 80 default_server;
server_name domain1;
root /var/www/domain1;
## how to serve proxy_cache if locations of domain_1 and domain_2 are the same ?
location / {
proxy_cache my_zone_domain_1;
add_header X-Proxy-Cache $upstream_cache_status;
include proxy_params;
proxy_pass http://domain1.com:8000;
}
location /api {
add_header X-Proxy-Cache $upstream_cache_status;
proxy_cache my_zone_domain_1;
proxy_pass http://domain1.com:8000/api;
}
}
configuration domain_2
server {
server_name www.domain2.com;
return 301 $scheme://domain2.com$request_uri;
}
server {
listen 3000;
server_name domain2.com;
root /var/www/example_site_2;
# common locations for all sites
location / {
include uwsgi_params;
uwsgi_pass unix:/var/www/example_site_2/domain2.sock;
}
# API
location /api {
include uwsgi_params;
uwsgi_param UWSGI_SCRIPT wsgi;
uwsgi_pass unix:/var/www/example_site_2/domain2.sock;
}
}
# Set cache directory for site
proxy_cache_path /tmp/nginx/domain2 levels=1:2 keys_zone=my_zone_domain_2:10m max_size=50m inactive=60m;
proxy_cache_key "$scheme$request_method$host$request_uri";
# Virtualhost/server configuration
server {
# I tried listening on other ports than 80, but kept having redirects on domain_1
listen 80;
server_name domain2;
root /var/www/domain2;
## how to serve proxy_cache if locations of domain_1 and domain_2 are the same ?
location / {
proxy_cache my_zone_domain_2;
add_header X-Proxy-Cache $upstream_cache_status;
include proxy_params;
proxy_pass http://domain2.com:3000;
}
location /api {
add_header X-Proxy-Cache $upstream_cache_status;
proxy_cache my_zone_domain_2;
proxy_pass http://domain2.com:3000/api;
}
}
Your domain_2 configuration uses proxy_pass http://domain2.com:8000 but there is only domain_1 server listens on the port 8000 so it gets to serve requests directed to domain_2.
I also recommend you to rethink usage of proxy_pass in your configuration, it isn't really necessary.
I found the culprit was Uwsgi : it was loaded from usr/bin folder, and not from virtual environment folder of my app.
Maybe virtualenv folder was corrupted: when I tried to re-install uwsgi (pip install uwsgi), it kept saying requirements satisfied until I noticed that which uwsgi was not loaded from virtualenv.
I had to remove and reinstall virtualenv folder with uwsgi and python modules.
Now applications were running (answer to the question), but proxy_server configuration has to be further adjusted in my case.
The following may be useful for people making use of url_for() directives in flask: url_for() directive routes to an absolute path, which may conflict with the nginx proxy.
Example: nginx proxy server listens on domains2.com on port 80, proxy_pass /path location to http://domain2.com:3000; if flask is redirecting a route to /path (with url_for()), the resulting url will be http://domain2.com:3000/path (because it follows the port specified in absolute path) instead of http://domain2.com/path (the url of the proxy).
Add proxy_set_header Host $http_host; to /path location to allow nginx proxy follow the correct redirect of your flask application.

nginx - (http / https) non-www to www redirection

I am have a website running on laravel 5 framework and hosted on DigitalOcean via laravel forge. I have just purchased a simple SSL Certificate from Namecheap for the sake of trying the certificate. Before installing the certificate everything was fine, i was able to load my website properly. After i install the certificate via Laravel Forge, my site is not loadable anymore (either http or https). I have no idea what is happening and from where to start debugging. Hopefully someone is able to provide me with some assistance.
I will provide you as much information as I can in below.
Nginx.conf via Laravel forge
server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
return 301 $scheme://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
root /home/forge/www.example.com/public;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/www.example.com/10772/server.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com/10772/server.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
client_max_body_size 128M;
index index.html index.htm index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
access_log off;
error_log /var/log/nginx/www.example.com-error.log error;
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
}
Server Details
VPS Provider: DigitalOcean
Deployment: Laravel Forge
Platform: Ubuntu 14.04 x64 vmlinuz-3.13.0-57-generic
Framework: Laravel 5
Domain reg: Namecheap
DNS Svr: ns1,ns2,ns3.digitalocean.com
CA: Comodo PositiveSSL
Update 1: according to the buddy below suggested to check iptables, this is what i've got
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT udp -- anywhere anywhere udp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT udp -- anywhere anywhere udp dpt:https
Update 2: curl -i test does show that the site has now being redirected to a https:// connection. But browser says ERR_CONNECTION_CLOSED
root#Apocalypse:/etc/nginx/ssl/www.example.com/10784# curl -i http://example.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.8.0
Date: Sat, 01 Aug 2015 09:52:53 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://www.example.com/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.8.0</center>
</body>
</html>
root#Apocalypse:/etc/nginx/ssl/www.example.com/10784# curl -i http://www.example.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.8.0
Date: Sat, 01 Aug 2015 09:53:24 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://www.example.com/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.8.0</center>
</body>
</html>
Update 3: openssl s_client return with this error
openssl s_client -connect www.example.com:443
CONNECTED(00000003)
140000289871520:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Update 4: I have found out the issue.. apparently this line
server {
listen 443 ssl;
server_name example.com;
return 301 $scheme://www.example.com$request_uri;
}
is causing the issue. once i remove it then everything works like a charm... but now my problem is how should i reroute https://example.com to https://www.example.com? Suppose that the above code is to perform that action.
Ok so I have resolved the issue. Now where do I start.
First
I would like to clarify that there is no problem with the certificate, Laravel forge and nginx configuration file. Everything was well setup and well configured.
Second
Like what I have done in my question above, configure your nginx.conf like such:
server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/www.example.com/10772/server.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com/10772/server.key;
return 301 $scheme://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
root /home/forge/www.example.com/public;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/www.example.com/10772/server.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com/10772/server.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
client_max_body_size 128M;
index index.html index.htm index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
access_log off;
error_log /var/log/nginx/www.example.com-error.log error;
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
}
Note that there is one thing I would like you to pay attention on in this section. When you are redirecting a https connection (port 433 to port 433), you are required to specify again the certificates and keys to be use. Naturally when the server performs a redirect, a new connection is being established therefore a new handshake sequence is required. That is why in my https://example.com redirection
server {
listen 443 ssl;
server_name example.com;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/www.example.com/10772/server.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com/10772/server.key;
return 301 $scheme://www.example.com$request_uri;
}
I would have to re specify the certificates or else the server will drop the connection since there is no credentials to be validated with. Once you have done with this, you should be half way till completion.
Third
In order to have a proper redirection, there are a few things you need to check and make sure it is configured properly.
Domain names to be configured in your DNS provider and your Hosting
provider must consist of both www and non-www A(Host) registry and
point to the same ip.
Make sure that your name servers are able to resolve non-www addresses (with or without https) into your desired address. Which in my case all http://example.com, http://www.example.com, https://example.com, into https://www.example.com. Performing this check you can use like #Wizzard's suggestion curl -i http://example.com/
Finally
Once everything has been properly configured, you should be on your way to a secured connection browsing.
Can you access the port 80 or port 443? Try running a
curl -i http://example.com/ on your command line, whats the error?
Can you check the nginx logs?
Is nginx even running, maybe restart it again?
service nginx restart
What about the firewall, is that open for port 443?
Checked iptables if installed?
iptables -L

#spinner{} element fails two worker when Nginx is the reverse proxy in front of Nitrogen

I have running my Nitrogen driven application directly however because i want to use Nginx load-balancing magic i found out that the progress notifier of Nitrogen, the Spinner is not showing at all. I followed the example as at Nitrogen configuration options - bottom of the page. The example code snippet at the link is shown below.
# My config for a site that I only want serving SSL content.
server {
listen 80;
server_name www.mysite.com, mysite.com;
access_log /var/log/nginx/mysite.com.access.log;
# rewrite all requests to be SSL
rewrite ^(.*) https://$host$1 permanent;
}
server {
listen 443;
server_name mysite.com www.mysite.com
access_log /var/log/nginx/mysite.ssl.access.log;
ssl on;
ssl_certificate ssl/mysite/mysite.com.crt;
ssl_certificate_key ssl/mysite/mysite.com.key;
ssl_client_certificate ssl/mysite/ca.crt;
location / {
# This installation is running on port 8021, as you can plainly see.
proxy_pass http://127.0.0.1:8000;
}
}
Without Nginx the spinner works fine. I am using Nitrogen over Yaws of release as stated in the RELEASE file [{release,"nitrogen","2.3.0-beta5","5.10.3",[...,...,...,...],permanent}]. I do not what I am not doing right.

Resources