Обратный прокси-сервер Nginx с Docker LetsEncrypt - PullRequest
Новая
       9

Обратный прокси-сервер Nginx с Docker LetsEncrypt

0 голосов
/ 03 июля 2018

Кто-нибудь видит, что я сделал не так с моим обратным прокси-сервером Nginx? Я получаю 502 Bad Gateway, и я не могу понять, где мои порты не так.

Nginx

/ и т.д. / Nginx / сайты с поддержкой / по умолчанию 

upstream reverse_proxy {
  server 35.237.158.31:8080;
}

server {
  listen 80;
  server_name 35.237.158.31;

  location / {                                                      
    proxy_pass http://reverse_proxy;
    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 Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_cache_bypass $http_upgrade;
  }

}

/ etc / nginx / sites-enabled / jesse.red [VHOST] 

upstream jessered {
    server 127.0.0.1:2600; # <-- PORT 2600
}
server {

  server_name jesse.red;
  #root /var/www/jesse.red/;

    # ---------------------------------------------------------------
    # Location
    # ---------------------------------------------------------------
    location / {
        proxy_pass          http://jessered;
        #proxy_http_version  1.1;
        proxy_set_header    Upgrade $http_upgrade;
        proxy_set_header    Connection 'upgrade';
        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-Proto $scheme;
        proxy_cache_bypass  $http_upgrade;
        proxy_read_timeout  90;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/jesse.red/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/jesse.red/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = jesse.red) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

  server_name jesse.red;
    listen 80;
    return 404; # managed by Certbot
}

Docker

Ниже он работает на 2600 

$ docker ps

9d731afed500        wordpress:php7.0-fpm-alpine   "docker-entrypoint.s…"   3 days ago          Up 17 hours         9000/tcp, 0.0.0.0:2600->80/tcp   jesse.red

/ вар / WWW / jesse.red / докер-compose.yml 

version: '3.1'
services:
  jessered:
    container_name: jesse.red
    image: wordpress:4-fpm-alpine
    restart: always
    ports:
      - 2600:80 # <-- PORT 2600
    env_file:
      - ./config.env  # Contains .gitignore params

Тестер Docker 

docker-compose logs

Attaching to jesse.red
jesse.red | WordPress not found in /var/www/html - copying now...
jesse.red | Complete! WordPress has been successfully copied to /var/www/html
jesse.red | [03-Jul-2018 11:15:07] NOTICE: fpm is running, pid 1
jesse.red | [03-Jul-2018 11:15:07] NOTICE: ready to handle connections

System 

$ ps aux | grep 2600

Ниже порт 2600 используется. 

root      1885  0.0  0.1 232060  3832 ?        Sl   Jul02   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 2600 -container-ip 172.20.0.2 -container-port 80

Я не уверен, что пошло не так, любая помощь действительно ценится. Я обыскивал много мест и не разобрался, прежде чем спросить.

1 Ответ

0 голосов
/ 03 июля 2018

При обработке запроса Nginx серверный блок выбирается так:

Проверка директивы listen для IP: точные совпадения портов, если совпадений нет, проверьте совпадения IP-адресов ИЛИ портов. IP-адреса без порта считаются портом 80.

Из этих совпадений он затем проверяет заголовок Host запроса на соответствие директиве server_name в сопоставляемых блоках. Если он находит совпадение, то этот сервер обрабатывает запрос, если нет, то при условии, что директива default_server не установлена, запрос будет передан на сервер, указанный первым в вашей конфигурации.

Таким образом, у вас есть server_name 35.237.158.31; на порту 80 и server_name jesse.red; также на порту 80

IP-адреса должны быть частью директивы listen, а не server_name, хотя это может соответствовать некоторым запросам. Предполагая, что к этому обращаются из внешнего мира, маловероятно, что jesse.red будет в чьих-либо заголовках хоста.

Если предположить, что совпадений нет, то он будет передан на любой сервер, который Nginx сначала найдет с совпадением портов, я предполагаю, что Nginx будет работать в алфавитном порядке при включении файлов, поэтому ваши конфигурации будут загружаться так:

  1. / и т.д. / Nginx / сайты с поддержкой / по умолчанию
  2. / и т.д. / Nginx / сайты с поддержкой / jesse.red

и теперь все ваши запросы на порт 80 без совпадения хоста или с IP-адресом в поле хоста проксируются на: 

upstream reverse_proxy {
  server 35.237.158.31:8080;
}

В любом случае, это мое предположение, ваши журналы Nginx, вероятно, дадут вам довольно определенный ответ.

...