Если SSL в Docker не работает, браузер может показывать ошибку сертификата, бесконечный редирект, 502, mixed content или обычный HTTP вместо HTTPS. В контейнерной схеме важно понимать, где заканчивается TLS.
Проверьте цепочку: DNS указывает на сервер, порты 80/443 доступны, reverse proxy видит контейнер, сертификат выпущен на нужный домен, приложение корректно понимает HTTPS за прокси.
Коротко: что сделать
- Проверить DNS домена и открытые порты 80/443
- Посмотреть логи reverse proxy и certbot/traefik
- Проверить docker compose ports и networks
- Проверить сертификат на домен и поддомен
- Проверить заголовки X-Forwarded-Proto
Основные причины
У таких сбоев редко бывает одна универсальная причина. Надежнее идти от факта к факту: где ошибка проявляется, какие данные проходят через систему, что изменилось перед поломкой и на каком шаге цепочка перестает работать.
- Контейнер приложения слушает порт, который не проброшен наружу
- Reverse proxy не подключен к нужной docker network
- Let’s Encrypt challenge не проходит из-за закрытого 80 порта
- Приложение генерирует HTTP-ссылки за HTTPS-прокси
- Сертификат выпущен на другой домен или устарел
Пошаговая диагностика
Диагностику лучше проводить на одном воспроизводимом примере. Так проще увидеть не общий шум, а конкретное место, где интерфейс, сервер, интеграция или внешняя служба начинают вести себя неправильно.
- Выполнить docker ps и проверить порты
- Открыть логи nginx/traefik/caddy
- Проверить curl -I по HTTP и HTTPS
- Проверить openssl s_client для домена
- Проверить переменные APP_URL, TRUSTED_PROXIES и HTTPS
Как исправить проблему
Исправление должно закрывать первопричину, а не только маскировать симптом. Если затронуты доступы, платежи, данные клиентов или серверные настройки, сначала сделайте резервную копию и проверьте правку на тестовом сценарии.
- Настроить reverse proxy на нужный container name и порт
- Подключить сервисы к общей docker network
- Открыть 80/443 и корректно настроить challenge
- Обновить переменные приложения для HTTPS
- Перевыпустить сертификат на нужные домены
Безопасный план решения
Не меняйте сразу все контейнеры. Сначала проверьте один домен и один сервис, добейтесь корректного HTTPS, затем переносите схему на остальные сервисы.
Чего не стоит делать
- Не хранить приватные ключи сертификатов в публичном репозитории
- Не пробрасывать лишние внутренние порты наружу
- Не отключать проверку сертификата в приложении как постоянное решение
- Не смешивать несколько reverse proxy на одном 443 порту без схемы
Что подготовить перед исправлением
- docker-compose.yml без секретов
- Домен и поддомены
- Логи reverse proxy
- Описание, какой контейнер должен открываться по HTTPS
FAQ
Почему HTTP работает, а HTTPS нет?
Часто 443 порт не направлен на reverse proxy или сертификат не выпущен на домен.
Почему возникает бесконечный редирект?
Приложение не понимает, что запрос уже пришел по HTTPS через прокси, и снова редиректит.
Нужен ли SSL внутри контейнера?
Обычно TLS завершается на reverse proxy, а до приложения идет внутренний HTTP по docker network.
Когда стоит обратиться за помощью
Помощь нужна, если на сервере несколько Docker-сервисов, продакшен-домены и нельзя долго держать HTTPS в нерабочем состоянии.
Итог
Проверьте DNS, порты, reverse proxy, сеть Docker и сертификат. Если нужно настроить SSL в Docker без простоев, пишите в Telegram @rabotator_support.