Исходная задача (в переработанном виде)

Имеется сервис, запущенный внутри Docker-контейнера. Он выполняет HTTP-запросы (POST) к внешним API: Firecrawl и DeepSeek. При запуске контейнера локально (проверено на машине разработчика) все внешние запросы выполняются корректно - ответ от сервисов приходит без задержек. Однако при деплое того же образа или сборке такого же Dockerfile на удалённом production-сервере происходит сбой: запросы к указанным API не завершаются, стек трейсы указывают на ошибку соединения, хотя из самого контейнера отработка через curl возвращает полноценный ответ от сервера.

Гипотеза причин неисправности: проблема с точками монтирования TLS-сертификатов в контейнерах, потеря промежуточных корневых сертификатов CA, кривая цепочка доверия пакета certifi/ca-certificates внутри образа или на уровне хоста. Ровно тот же HTTP-результат возможен при несоответствии DNS-резолвинга / настройке прокси.

Требования к итоговому решению / ожидаемому ответу

• Устранить или настроить возможность устойчивых HTTPS-соединений с api.firecrawl.com (домен заменён) и другом внешнем хосте из любого контейнера данного приложения - вне зависимости от версии образа Python и хост машины.
• При диагностике не предлагать создавать отдельные открытые прокси, вместо этого лечить корневую причину - комплект SSL/TLS-файлов.
• Допускать минимальные правки Dockerfile (формируется итог-ответ).

Необходимые зависимости / стрем в проекте

• Базовый образ: вариант Python (например python:3.12-slim).
• Вытягивание данных через:

• [code разметок библиотек]: например requests, httpx

• Наружу поднимается api порт - он же консюмит те сайты.
• Проект располагается в частном GitHub-репозитории.

Критерий успеха итоговой техзаписки

Тот, у кого возник такой запрос на бирже - понимание картины сразу на 100% заголовка, и студиозы уверенно предлагают фикс сертификатов, а не "отключить SSL verify False" не из микросервиса.