drhider/History/2026-07-12-sonnet-query-timeout.md

Запрос к Соннету — 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 сервис → под