33 lines
2.2 KiB
Markdown
33 lines
2.2 KiB
Markdown
# Запрос к Соннету — ERR_TIMED_OUT при открытии нового окна (2026-07-12)
|
||
|
||
## Симптом
|
||
|
||
DrHider на Managed Flask (Штурвал/pythonk8s). При открытии страницы в НОВОМ окне браузера — ERR_TIMED_OUT (20+ секунд). Старые вкладки работают нормально.
|
||
|
||
## Факты
|
||
|
||
- Изнутри кластера (kubectl exec → curl): HTTP 200 за 2.1 секунды
|
||
- Снаружи (браузер, curl с локальной машины): таймаут 10+ секунд
|
||
- v1 работало с gunicorn (CMD: `gunicorn --bind :5000 --worker-class gevent`)
|
||
- Сейчас: `app.run(host="0.0.0.0", port=5000)` — Flask dev server (Werkzeug)
|
||
- Страница: 12 KB HTML, 2 статических файла (logo.svg, favicon.svg — оба 2.8 KB)
|
||
- Ноль внешних зависимостей (никаких CDN, шрифтов, JS-библиотек)
|
||
- HTTP-заголовки: Cache-Control: no-cache, no-store, must-revalidate
|
||
- Штурвал запускает: cd site && python app.py
|
||
|
||
## Вопросы
|
||
|
||
1. Может ли Flask dev server (Werkzeug) быть причиной ERR_TIMED_OUT на новых соединениях, в то время как gunicorn работал нормально?
|
||
2. Если да — какой механизм? (keep-alive, thread pool, socket backlog?)
|
||
3. Если нет — что ещё может вызывать таймаут именно на НОВЫХ окнах при работающих старых?
|
||
4. Нужно ли вернуть gunicorn или есть другой способ заставить app.run() работать стабильно?
|
||
5. Может ли `Cache-Control: no-store` заставлять браузер делать лишние запросы при открытии нового окна?
|
||
|
||
## Контекст платформы
|
||
|
||
Штурвал — Managed Flask на Kubernetes:
|
||
- Запускает: `cd /var/www && pip install -r requirements.txt && cd site && python app.py`
|
||
- Readiness probe: `tcp-socket :5000`
|
||
- Нет Dockerfile, нет nginx перед приложением
|
||
- Ingress: внешний LoadBalancer → ClusterIP сервис → под
|