I'm trying to run a squid server behind nginx.
I configured nginx like this:
server {
listen 8080;
location / {
proxy_pass http://localhost:3128;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Then I set my http network proxy to:
my-nginx-server-address:8080
So when I try to view the Google homepage, the nginx will get the request:
Get http://www.google.com/ HTTP/1.1
However when nginx pass the request to squid it will change the request_uri to
/
So squid won't work.
Is there any way I can set the request_uri back to http://www.google.com then pass it to squid? Or any other ways I can run squid behind nginx?
Try proxy_set_header Request-URI $request_uri;
In reply to your comment, you may also prefer to add:
upstream _squid {
server localhost:3128;
}
server {
...
proxy_pass http://_squid/$host$uri;
}
Related
I am setting up a reverse proxy on Nginx, and the client request has a header X-OUTBOUND-URI, which will then hit my reverse proxy on a particular port.
I am trying to do a proxy_pass on the variable $http_x_outbound_uri, but there is a resolver error.
server {
listen 8082;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
proxy_pass $http_x_outbound_uri;
}
}
This is the curl command that is used: curl localhost:8082 -H "X-OUTBOUND-URI: http://localhost:9001", and I have a webserver running on port 9001.
Am I doing this wrongly? Also, for this use case, is it more suitable to do a redirect instead. Thanks.
For those who have encountered the same issue, I managed to resolve this issue by changing localhost to 127.0.0.1, otherwise, we have to set a resolver. I found the explanation in another post.
I have a task to connect a jitsi server with my existing domain. The jitsi server should be running in a subpath like https://dev.example.com/video.
I have installed jitsi in aws with hostname https://dev.example.com.
For this to work I have to set up an nginx block that will remove /video while sending a request to the jitsi server and add /video on the responses.
The plan was to add an upstream in my nginx as follows.
upstream jitsi {
server 10.10.10.20:443;
}
location /video/ {
rewrite ^/video/(.*) /$1 break;
proxy_pass https://jitsi/$uri$is_args$args;
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect https://dev.example.com/ https://dev.example.com/video/;
}
The rewrite will strip away the /video and the rest is supposed to add it on the response. But when loading the page, browser is showing 404 for some of the internal links.
eg:
https://dev.example.com/libs/do_external_connect.min.js?v=1
[HTTP/1.1 404 Not Found 124ms]
https://dev.example.com/libs/lib-jitsi-meet.min.js?v=4466
[HTTP/1.1 404 Not Found 123ms]
https://dev.example.com/libs/app.bundle.min.js?v=4466
[HTTP/1.1 404 Not Found 123ms]
https://dev.example.com/static/pwa/registrator.js
I could clearly see that the last part which is supposed to add /video into the URL is not working correctly.
What am I doing wrong here?
Thanks in advance
I had a proxy server which redirects communications to some api on customer side via https. When I use configuration with set upstream variable (proxy_pass $upstream_endpoint$request_uri;), the DNS resolving for this domain (dynamic changing IP adress) is working well but I get response 403 unauthorized.
When I use configuration without upstream (proxy_pass https://api-test.example.com/api/), point directly to customer domain it works well, I am getting response 200 but DNS resolver is not working anymore..
Nginx config:
location /api-test.example.com/api/ {
resolver 10.100.10.1 valid=5s;
set $upstream_endpoint https://api-test.example.com;
proxy_pass $upstream_endpoint$request_uri;
#proxy_pass https://api-test.example.com/api/;
proxy_ssl_name api-test.example.com;
proxy_ssl_server_name on;
proxy_set_header Host api-test.example.com;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
By adding a URI to the proxy_pass statement, the requested URI is rewritten before passing it upstream. See this docuement for details.
So the URI /api-test.example.com/api/foo is rewritten to /api/foo.
You can achieve the same behaviour with a rewrite...break statement. See this document for details.
location /api-test.example.com/api/ {
rewrite ^/api-test.example.com(.*)$ $1 break;
set $upstream_endpoint https://api-test.example.com;
proxy_pass $upstream_endpoint;
...
}
I'm setting up a web/app/db stack, and the nginx proxy configuration isn't working the way I thought it would.
so here is an example of the stack...the url of the application is:
https://testapp.com
here is the nginx config:
server {
listen 8886;
server_name _;
root /usr/share/nginx/html;
include /etc/nginx/default.d/*.conf;
#ELB
if ($http_user_agent = 'ELB-HealthChecker/2.0') {
return 200 working;
}
#HTTP to HTTPS
if ($http_x_forwarded_proto != 'https') {
return 301 https://$host$request_uri;
}
location / {
set $proxy_upstream_name "testapp.com";
port_in_redirect off;
proxy_pass http://internal-alb.amazonaws.com:8083/;
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-Host $server_name;
proxy_set_header Access-Control-Allow-Origin $http_origin;}
The app is proxied to an internal AWS alb, and it forwards it to a single (at this point) application server.
I'm able to get the site to serve. However, the application creates a redirect on login, and I get the following response.
Request URL:https://testapp.com/login
Request Method:POST
Status Code:302
Remote Address:34.192.444.29:443
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-language:en-US
content-length:0
date:Mon, 11 Sep 2017 18:35:34 GMT
location:http://testapp.com:8083/testCode
server:openresty/1.11.2.5
status:302
The redirect fails because it's being served on 443, not 8083.
For some reason the app or the proxy isn't updating the port as it doing it's reverse proxy thing, so that the redirect has the proxied port NOT the actual application port 443.
What do I need to do with nginx config to get it to redirect correctly.
thanks.
myles.
The normal behaviour of the nginx is to rewrite the upstream address to the address the page was served from. It looks like instead of using your upstream address (http://internal-alb.amazonaws.com:8083/), your app is responding using a mixture of the two (http://testapp.com:8083). You can either change the app behaviour, or, to fix it at the nginx level, can use the proxy_redirect directive.
I'm reasonably sure the directive to fix this is proxy_redirect http://testapp.com:8083/ https://testapp.com/;
I want to achieve the following:
Request Host:
http://example.com.proxy.myserver.com
Should be rewritten to
http://example.com
and passed to a squid server via nginx proxypass.
server {
listen 80;
server_name ~^(?<subdub>.*)\.proxy\.myserver\.com$;
location / {
rewrite ^ $scheme://$subdub break;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $scheme://$subdub;
proxy_set_header Request-URI $scheme://$subdub;
proxy_pass http://localhost:3128;
proxy_redirect off;
}
}
The problem is, that nginx redirects this request immediately to http://example.com
Any ideas how to get this working?
301 redirect is exactly what nginx shall do with that rewrite rule: because you put $scheme://$subdub at the replacement part, nginx will do a 301, ignoring that "break" flag.
If the replacement string begins with http:// then the client will be redirected, and any further rewrite directives are terminated.
Are you trying to "rewrite" or "redirect"? If it's just for rewrite, you can remove that rewrite directive:
rewrite ^ $scheme://$subdub break;
and it will work because your upstream server could rely on the HOST header to determine the traffic target (virtual hosting).
Also your host header sent to the upstream server is wrong. It should be
proxy_set_header Host $subdub;
$scheme should not be put in the Host header.