可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I've a service listening to 8080 port. This one is not a container.

Then, I've created a nginx container using oficial image:

docker run --name nginx -d -v /root/nginx/conf:/etc/nginx/conf.d -p 443:443 -p 80:80 nginx

After all:

# netstat -tupln | grep 443
tcp6       0      0 :::443                  :::*                    LISTEN      3482/docker-proxy
# netstat -tupln | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN      3489/docker-proxy
tcp6       0      0 :::8080                 :::*                    LISTEN      1009/java

Nginx configuration is:

upstream eighty {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name eighty.domain.com;

    location / {
      proxy_pass                        http://eighty;
    }
}

I've checked I'm able to connect with with this server with # curl http://127.0.0.1:8080

 <html><head><meta http-equiv='refresh'
 content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body
 style='background-color:white; color:white;'>
 ...

It seems running well, however, when I'm trying to access using my browser, nginx tells bt a 502 bad gateway response.

I'm figuring out it can be a problem related with the visibility between a open by a non-containerized process and a container. Can I container stablish connection to a port open by other non-container process?

EDIT

Logs where upstream { server 127.0.0.1:8080; }:

2016/07/13 09:06:53 [error] 5#5: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 62.57.217.25, server: eighty.domain.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "eighty.domain.com"
62.57.217.25 - - [13/Jul/2016:09:06:53 +0000] "GET / HTTP/1.1" 502 173 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" "-"

Logs where upstream { server 0.0.0.0:8080; }:

62.57.217.25 - - [13/Jul/2016:09:00:30 +0000] "GET / HTTP/1.1" 502 173 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" "-" 2016/07/13 09:00:30 [error] 5#5: *1 connect() failed (111: Connection refused) while connecting to upstream, client:
62.57.217.25, server: eighty.domain.com, request: "GET / HTTP/1.1", upstream: "http://0.0.0.0:8080/", host: "eighty.domain.com" 2016/07/13 09:00:32 [error] 5#5: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 62.57.217.25, server: eighty.domain.com, request: "GET / HTTP/1.1", upstream: "http://0.0.0.0:8080/", host: "eighty.domain.com"
62.57.217.25 - - [13/Jul/2016:09:00:32 +0000] "GET / HTTP/1.1" 502 173 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" "-"

Any ideas?

回答1:

The Problem

Localhost is a bit tricky when it comes to containers. Within a docker container, localhost points to the container itself. This means, with an upstream like this:

upstream foo{
  server 127.0.0.1:8080;
}

upstream foo{
  server 0.0.0.0:8080;
}

you are telling nginx to pass your request to the local host. But in the context of a docker-container, localhost (and the corresponding ip addresses) are pointing to the container itself:

by addressing 127.0.0.1 you will never reach your host machine, if your container is not on the host network.

Solutions

Host Networking

You can choose to run nginx on the same network as your host:

docker run --name nginx -d -v /root/nginx/conf:/etc/nginx/conf.d --net=host nginx

Note that you do not need to expose any ports in this case.

This works though you lose the benefit of docker networking. If you have multiple containers that should communicate through the docker network, this approach can be a problem. If you just want to deploy nginx with docker and do not want to use any advanced docker network features, this approach is fine.

Access the hosts remote IP Address

Another aproach is to reconfigure your nginx upstream directive to directly connect to your host machine by adding its remote IP address:

upstream foo{
  //insert your hosts ip here
  server 192.168.99.100:8080;
}

The container will now go through the network stack and resolve your host correctly:

You can also use your DNS name if you have one. Make sure docker knows about your DNS server.

回答2:

For me helped this line of code proxy_set_header Host $http_host;

server {
   listen            80;
   server_name  localhost;
location / {
   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;
   proxy_set_header Host $http_host;
   proxy_set_header X-NginX-Proxy true;

   proxy_redirect off;
   proxy_pass http://myserver;
}

回答3:

nginx.sh

ip=$(ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1' | head -n 1)

docker run --name nginx --add-host="host:${ip}" -p 80:80 -d nginx

nginx.conf

location / {
    ...
    proxy_pass http://host:8080/;
}

It‘s works for me

回答4:

What you can do is configure proxy_pass that from container perspective the adress will be pointing to your real host.

To get host address from container perspective you can do as following on Windows with docker 18.03 (or more recent):

Run bash on container from host where image name is nginx (works on Alpine Linux distribution):

 docker run -it nginx /bin/ash

Then run inside container

/ # nslookup host.docker.internal

Name:      host.docker.internal
Address 1: 192.168.65.2

192.168.65.2 is the host's IP - not the bridge IP like in spinus accepted answer.

I am using here host.docker.internal:

The host has a changing IP address (or none if you have no network access). From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host. This is for development purpose and will not work in a production environment outside of Docker for Windows.

Then you can change nginx config to: proxy_pass http://192.168.65.2:{your_app_port};

and it should work fine.

Remember to provide the same port as your local application runs with.