My doubt begins because I have an nginx and a number of dockerized apis in a virtual machine. In my nginx.conf file I have each api defined as follows:
location /items {
set $backend_server http://api-items:8080;
# Access swagger via proxy
location ~ ^(/items/).*\.(js|css|html|png|json)$ {
set $backend_server http://api-items:8080;
rewrite ^/items/(.*)$ /$1 break;
proxy_pass $backend_server;
}
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
proxy_pass $backend_server/items;
}
For nginx to build correctly I need to have all the APIs built in my virtual machine.
The question is if I can have this directive for a service (url) that is not working. I don't know if there is a way to mark a url so that if the proxy_pass doesn't work, nginx doesn't throw you down.
Conditionals in location directives for nginx configuration
Related
Placed frontend and backend in nginx. I'm trying to correctly configure that after authorization, nginx redirected me to the original page.
Nginx Conf:
##Frontend
server_name atlas.com;
location / {
root /ops/front_2.0/dist/;
index index.html;
}
##Backend
location /api {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
With this configuration, the backend does not work, I will not get to the authorization page and a 404 Not Found error occurs.
But if, with the same settings, you place the Backend on another domain name, for example:
server_name server.atlas.com;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
}
Then everything works fine. But such a solution does not suit me, since it is not convenient to use for Frontend, since a CORS error is raised.
I am new to the nginx config.
I am trying to do a load balancing example with nginx and wcf rest service in windows platform.
Here is what I have in my conf/nginx.conf file:-
upstream servers_customserver {
server 127.0.0.1:62133;
server 127.0.0.1:64897;
server 127.0.0.1:64921;
}
server {
listen 8070;
location /test {
proxy_pass http://servers_customserver/;
}
My motive is whenever, I try to enter a website name which contains "/test" then redirect to one of the urls in the
"servers_customserver".
Nginx is fine in localhost:8070.
But whenever I did localhost:8070/test, I am getting "404 Not Found nginx/1.12.0" in the browser. I am sure that my services are up.
Do, I need to work with my services in IIS or any webservers to make this to work?
Could some one guide me in solving this error.
Thanks.
Luckily,
After adding the following steps to the location block, the load balancing stuff works for me.
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-Host #server_name;
proxy_redirect off;
Thanks.
I've installed GitLab on a virtual machine in Microsoft Azure in which I also have an Apache2 web server that should respond with some static websites.
Since GitLab has an embedded NGinX web server I thought that it would have been sufficient to just make these two changes:
Make apache listen to another port rather than 80 (I changed it to 8090)
Add a server block to GitLab's NGinX (firstly by adding this configuration to gitlab.rb nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;" and then by creating the following block in /etc/nginx/conf.d/serverblock.conf)
server {
root /var/www/;
server_name .notgitlabdomain.com;
access_log /etc/nginx/logs/notgitlabdomain_access.log;
error_log /etc/nginx/logs/notgitlabdomain_error.log;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass 127.0.0.1:8090;
add_header X-Upstream $upstream_addr;
add_header NLC_S "s";
}
}
The problem is that this is not working so far. I opened and checked whether the nginx.conf (in /var/opt/gitlab/nginx/conf/) file is actually reading the server block I added and it is. But when I follow a link in my notgitlabdomain.com domain it redirects me to notgitlabdomain.com/users/sign_in with a Sass error that couldn't import a some css files.
Open develop tools and check the request.
I guess this issue is related about the configuration of gitlab (domain url)
I have common problem anyone can encounter when you run nginx as a reverse proxy server for apache, i want to add double proxy_pass variables to the nginx conf. file but this doesn't seems to be allowed by nginx.
For example situations i have is
In my website i have chat engine runs by openfire, which runs on port 5280 with Jetty and i have set the apache proxy pass directive set as
ProxyPass /member-chat http://xyx.com:5280/http-bind
ProxyPassreverse /member-chat http://xyx.com:5280/http-bind
ProxyRequests Off
but i want to pass anything that comes to the "/member-chat" send directly to the chat-server rather than the apache, because then what apache would do is again proxy pass that to the openfire (member-chat), which takes more time and useless loading for apache.
when i add the nginx as the proxy server i want to add like this below but this didn't work, for some reason, it cant find the location gives me 404 error.
location / {
proxy_pass http://85.xxx.yyy.2x2:7080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
}
location ~ ^/member-chat {
proxy_pass http://85.xxx.yyy.2x2:5280;
proxy_connect_timeout 300;
}
I believe you missed out on specifying the URI for the Jetty service. With your current configuration, the request that will land up on Jetty port would be:
http://85.xxx.yyy.2x2:5280/member-chat
This is as per the proxy_pass documentation.
If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI
I don't think that is what you expect looking at your Apache configuration for the same. Try configuring the URI for proxy_pass directive as you have done for Apache.
location ~ ^/member-chat {
proxy_pass http://85.xxx.yyy.2x2:5280/http-bind;
proxy_connect_timeout 300;
}
I'm flummoxed.
I have a server that is primarily running couchdb over ssl (using nginx to proxy the ssl connection) but also has to serve some apache stuff.
Basically I want everything that DOESN'T start /www to be sent to the couchdb backend. If a url DOES start /www then it should be mapped to the local apache server on port 8080.
My config below works with the exception that I'm getting prompted for authentication on the /www paths as well. I'm a bit more used to configuring Apache than nginx, so I suspect I'm mis-understanding something, but if anyone can see what is wrong from my configuration (below) I'd be most grateful.
To clarify my use scenario;
https://my-domain.com/www/script.cgi should be proxied to
http://localhost:8080/script.cgi
https://my-domain.com/anythingelse should be proxied to
http://localhost:5984/anythingelse
ONLY the second should require authentication. It is the authentication issue that is causing problems - as I mentioned, I am being challenged on https://my-domain.com/www/anything as well :-(
Here's the config, thanks for any insight.
server {
listen 443;
ssl on;
# Any url starting /www needs to be mapped to the root
# of the back end application server on 8080
location ^~ /www/ {
proxy_pass http://localhost:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
# Everything else has to be sent to the couchdb server running on
# port 5984 and for security, this is protected with auth_basic
# authentication.
location / {
auth_basic "Restricted";
auth_basic_user_file /path-to-passwords;
proxy_pass http://localhost:5984;
proxy_redirect off;
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-Ssl on;
}
}
Maxim helpfully answered this for me by mentioning that browsers accessing the favicon would trigger this behaviour and that the config was correct in other respects.