Как я могу продолжить устранение ошибки «502 Bad Gateway»?

Я запускаю набор служб в среде Docker. Все службы находятся за одним и тем же контейнером обратного прокси-сервера nginx, который шифрует с помощью letsencrypt и разделяет входящий трафик на основе поддоменов.

Сегодня внезапно (пока я возился с другой службой) мой контейнер Nextcloud начал возвращать 502 Bad Gateway при доступе через обратный прокси.

Все остальные службы в порядке.

При проверке ошибки .log , в который nginx записывает эти ошибки. Я вижу много таких ошибок:

512 connect() failed (111: Connection refused) while connecting to upstream

Это заставляет меня думать, что что-то не так с экземпляром контейнера Nextcloud.

Итак, я проверил состояние контейнера (я недавно перезапустил систему, поэтому до 13 минут):

docker ps -a | grep Nextcloud
6a4cd6dde4f6   nextcloud:21.0.1                      "/entrypoint.sh apac…"   About an hour ago   Up 13 minutes             80/tcp                                                               Nextcloud

Здесь все в порядке. Поэтому я проверил вывод контейнера, запустив docker-compose в терминале (в отличие от его запуска как демона в фоновом режиме), который вообще не дал мне нового интересного вывода. Мои обновления браузера, похоже, вообще не доходили до контейнера Nextcloud.

После этого я хотел проверить, реагирует ли контейнер Nextcould вообще, поэтому я перенаправил порт хоста 5555 на порт 80 контейнера nextcloud и подключился к IP-адресу хоста напрямую через порт 5555. Это сработало. Я получил страницу «Доступ через ненадежный домен», что имеет смысл, поскольку я обращался к ней напрямую через IP-адрес хоста.

Хорошо, значит, обратный прокси-контейнер обнаруживает , в соединении отказано , а контейнер Nextcloud вообще не получает никаких запросов, но, похоже, в остальном работает нормально.

Затем я создал временный контейнер для устранения неполадок Ubuntu и подключил его к той же сети докеров, что и обратный прокси-контейнер и контейнер Nextcloud. После установки некоторых инструментов я выполнил следующие команды:

root@491b7ef0f34f:/# ping Nextcloud
PING Nextcloud (10.10.7.3) 56(84) bytes of data.
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=1 ttl=64 time=0.127 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=3 ttl=64 time=0.083 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=4 ttl=64 time=0.085 ms
^C
--- Nextcloud ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.080/0.093/0.127/0.019 ms

root@491b7ef0f34f:/# nmap -sV -p- Nextcloud
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-25 18:43 UTC
Nmap scan report for Nextcloud (10.10.7.3)
Host is up (0.0000090s latency).
rDNS record for 10.10.7.3: Nextcloud.couplernets_nextcloud
Not shown: 65534 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.38 ((Debian))
MAC Address: 02:42:0A:0A:07:03 (Unknown)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 7.64 seconds

root@491b7ef0f34f:/# wget Nextcloud:80/index.html
--2021-04-25 18:45:28--  http://nextcloud/index.html
Resolving nextcloud (nextcloud)... 10.10.7.3
Connecting to nextcloud (nextcloud)|10.10.7.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 156 [text/html]
Saving to: 'index.html.1'

index.html.1        100%[===================>]     156  --.-KB/s    in 0s

2021-04-25 18:45:28 (7.66 MB/s) - 'index.html.1' saved [156/156]

Это говорит мне, что экземпляр Nextcloud должен быть в порядке, поскольку его порт открыт, и я могу получить доступ к файлу index.html без проблем.

Затем я пошел проверить конфигурацию обратного прокси-сервера nginx.

 server {
    listen 443 ssl;
    listen [::]:443 ssl;

    #Add HSTS preload header
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    #Remove revealing headers
    server_tokens off;
    proxy_hide_header X-Powered-By;

    server_name <cloud.domain.topdomain>;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        proxy_max_temp_file_size 2048m;
        proxy_pass http://Nextcloud:80/;
    }
}

Эта конфигурация такая же, как и у всех других служб, которые проходят через тот же контейнер обратного прокси. Единственное, что отличается, - это параметры конфигурации server_name и proxy_pass .

Отсюда я понятия не имею, что мне попробовать дальше. Помогите, пожалуйста. Любая помощь очень ценится.

-1
задан 26 April 2021 в 17:18
1 ответ

Оказалось, что проблема была во внутреннем разрешении имен IP в контейнере Docker, который вел себя странно.

Когда я подключился к контейнеру обратного прокси и выполнил ping Nextcloud, контейнер неправильно разрешил IP-адрес контейнера Nextcloud. Поэтому всякий раз, когда я пытался отправить что-либо в контейнер Nextcloud, сетевой уровень docker неправильно определял IP контейнера Nextloud и отправлял трафик в неправильный контейнер, что приводило к отказу в подключении.

Моим решением было отключить контейнер, который был неправильно разрешен. После этого к моему контейнеру Nextcloud можно было обратиться, используя имя хоста "Nextcloud".

Что вызвало проблему, остается неясным. Я вернусь сюда, если когда-нибудь узнаю.

0
ответ дан 7 May 2021 в 21:06

Теги

Похожие вопросы