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

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

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

Все остальные сервисы работают нормально.

При просмотре error.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.

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

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

Затем я создал временный контейнер Ubuntu для устранения неполадок и подключил его к той же сети Docker, что и контейнер обратного прокси, и контейнер 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;

    #Добавить заголовок HSTS preload
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" всегда;

    #Удалить раскрывающие заголовки
    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.

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

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

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

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

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

В моем случае это была проблема с брандмауэром. Я отключил брандмауэр, и всё заработало.

Подсказка пришла, когда я сделал запрос к IP docker, который корректно вывел HTML главную страницу.

sudo ip addr show docker0

4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:a9:60:8e:f4 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

curl 172.17.0.1:5870

У меня было приложение, работающее на порту 5870, и до отключения брандмауэра:

curl 127.0.0.1:5870
curl: (56) Recv failure: Connection reset by peer

curl 0.0.0.0:5870
curl: (56) Recv failure: Connection reset by peer

После этого я получаю вывод HTML страницы.