Друзі, привіт! Як ваш день?

Добрався я до розбору наших пулів))
Сьогодні розберемо цей кейс і він реально часто трапляється після деплою, особливо коли маєш справу з контейнерами, NGINX і REST-запитами)

Чому не (A) - пошкоджений SSL?
Тут якби був битий сертифікат, то в логах було б видно “SSL handshake failed”, “certificate expired” або “bad PEM”.
А тут сервер взагалі не відповів, тобто він ще не встиг піднятись до стану ready.

Чому не (B) - CORS?
CORS-ошибка виглядає зовсім інакше.
Тоді REST відповів би 403 або 401, але не 503. Тут ми навіть не дійшли до CORS - запит просто не дочекався сервісу.

Чому не (C) - кеш браузера?
Якщо сервер не слухає порт, кеш не допоможе. Браузеру нема куди стукатись, тому він навіть не отримає респонсу.

Чому всеж (D)
Контейнер з NGINX або бекендом стартує, але ще не готовий приймати запити (порт не слухає).
У цей момент клієнт або frontend вже відправляє REST-запит - і отримує 503 Service Unavailable, бо NGINX ще не “прокинувся”.
Це реальн типова історія для Docker або Kubernetes - коли healthcheck ще не пройшов, але трафік уже пішов.

Як це можно перевірити? та принцепі не проблема
Подивіться docker logs або kubectl describe pod - чи встигає сервіс реально стартувати до того, як приходить запит.
У NGINX-логах буде connect() failed (111: Connection refused) - це і є знак, що порт ще не слухає.

Що я маю вам сказати
Це прям класика після деплою - коли все працює, але щось “іноді падає”.
А насправді просто REST побіг швидше, ніж NGINX встав на ноги )

Хто вгадав із першого разу то вам респект)
А хто ні, тепер точно не попадетесь на цей “сонний NGINX”

Всім гарного вечора, і настрою

Обняв🤗