При первом заходе на сайт страница зависает — как это можно исправить?

На сайте на российском VPS появилась проблема: при заходе с новых браузеров (с которых ранее не посещали сайт) страница зависает более минуты и только затем отображается, либо вообще не загружается и браузер показывает Empty Response или Connection Closed. После одного успешного захода с этого же браузера сайт далее работает стабильно. При отключении HTTPS сайт загружается нормально. Сайт написан на Django.
  • 19 мая 2026 г. 22:01
Ответы на вопрос 5
Кратко — это почти всегда не «Django», а проблема на уровне TLS/сетевого стека: первый HTTPS‑хэндшейк блокируется (таймаут) и потом кеш/ответ остаётся — поэтому повторный заход идёт быстро. Самые частые причины и как их проверить/исправить.

1) OCSP / stapling (очень часто)
- Что происходит: при первом подключении сервер или браузер пытается проверить статус сертификата через OCSP. Если сервер настроен на OCSP stapling, nginx/Apache может попытаться достать OCSP‑ответ от CA при первом запросе и зависнуть, если до OCSP‑респондеров нет доступа. Если stapling выключен, браузер сам делает OCSP запрос — аналогичная задержка только при первом визите.
- Как проверить:
  - Посмотреть OCSP URI из сертификата:
    openssl x509 -in /path/to/cert.pem -noout -ocsp_uri
  - С клиента (сервер/ваш ПК) попробовать запрос к OCSP:
    curl -v http://<ocsp_responder_uri>
  - Проверить stapling статус:
    openssl s_client -connect your.domain:443 -servername your.domain -status
    (в выводе будет секция OCSP response)
  - Посмотреть лог веб‑сервера (error.log) на предмет ssl_stapling ошибок.
- Варианты исправления:
  - Разрешить исходящие HTTP (80) соединения к OCSP‑респондеру (провайдер/фаервол VPS часто блокирует).
  - Правильно настроить stapling: ssl_stapling on; ssl_trusted_certificate (полный chain) и ssl_stapling_verify для nginx/соответствующие опции для Apache.
  - Если не удаётся обеспечить доступ к OCSP, временно отключить stapling или настроить сервер так, чтобы не блокировал при ошибке (в некоторых версиях серверы тянут ответ синхронно — надо обновить/перенастроить).
  - Можно также периодически подтягивать OCSP и кешировать (зависит от сервера/версии).

2) Нехватка энтропии (blocking RNG) при генерации ключей
- Симптомы: длительная задержка на первый TLS‑хэндшейк в виртуалках/контейнерах с низкой энтропией. После генерации случайных данных последующие хэндшейки быстрые.
- Как проверить:
  - На сервере посмотреть доступную энтропию:
    cat /proc/sys/kernel/random/entropy_avail
    (если значение очень низкое — <100 — может быть проблемой)
  - Посмотреть, не генерирует ли сервер DH параметры при первом подключении (проверьте наличие dhparam файла и его длину).
- Исправление:
  - Установить демона генерации энтропии: haveged или rngd (apt install haveged или yum install haveged) и включить сервис.
  - Предварительно сгенерировать dhparam (openssl dhparam -out /etc/ssl/dhparam.pem 2048) и подставить в конфиг, чтобы не генерировалось в runtime.

3) IPv6 / DNS fallback
- Симптом: браузер пытается по IPv6 (AAAA) — соединение с 443 по IPv6 не отвечает/закрывается, потом таймаут и переход на IPv4. При HTTP (порт 80) сервер может принимать IPv6, поэтому там нет задержки.
- Проверка:
  - dig AAAA your.domain
  - curl -v -4 https://your.domain/ и curl -v -6 https://your.domain/
- Исправление:
  - Удалить/правильно настроить AAAA, либо убедиться что сервер слушает на IPv6 и на 443.
  - Можно временно отключить IPv6 на сервере, если он не используется.

4) Блок исходящих соединений/фаервол провайдера
- Провайдеры иногда блокируют исходящие HTTP/OCSP. Проверьте iptables/nftables и провайдерский firewall.

5) Диагностика сетевого трафика
- Посмотрите tcpdump во время проблемного захода, чтобы понять где виснет:
  sudo tcpdump -n -i any host <client_ip> and port 443 -w capture.pcap
- Логи nginx/apache: /var/log/nginx/error.log, access.log.

Рекомендуемый порядок действий (быстрое «что сделать сейчас»)
1. Выполните на сервере:
   - openssl s_client -connect your.domain:443 -servername your.domain -status
   - openssl x509 -in /path/to/cert.pem -noout -ocsp_uri
   - curl -v http://<ocsp_responder_uri>  (проверить доступность OCSP)
   - cat /proc/sys/kernel/random/entropy_avail
   - dig AAAA your.domain
2. Если OCSP‑респондер недоступен — либо разрешите исходящие соединения, либо временно отключите stapling/перенастройте.
3. Если entropy низкая — установите haveged/rngd.
4. Если есть AAAA-адрес — протестируйте IPv6 и исправьте (или уберите AAAA).

Если хотите, пришлите:
- вывод openssl s_client -connect your.domain:443 -servername your.domain -status
- значение entropy (cat /proc/sys/kernel/random/entropy_avail)
- результат dig AAAA и dig A
и я подскажу конкретно по вашей конфигурации.
падает на TLS-handshake ещё до Django — до приложения запрос просто не доходит. Chrome 124+ при первом визите пробует post-quantum key share (X25519Kyber768Draft00), твой OpenSSL это не понимает — отсюда bad key share и зависание. Со второго раза браузер уже запоминает что PQ не тянешь и не пробует. <br/> <br/> Добавь в server-блок nginx: <code>ssl_ecdh_curve X25519:prime256v1:secp384r1;</code> и <code>nginx -t &amp;&amp; systemctl reload nginx</code>
У меня такое было на ростелекоме, с любыми сайтами, хоть nalog.ru, в очень случайное время (примерно раз в 2-3 часа), со случайным сайтом (если долго на него не заходить). Если повторить запрос, то через примерно секунду чинится. <br/> <br/> 'Починилось' при указании DNS от провайдера (не 8.8.8.8!), точнее глюков стало сильно меньше/реже (это странее всего). Что очень сильно усложняет настройку, если нужен одновременно и vpn и роутинг в российские сети. <br/> <br/> У меня есть теория, их вундервафля собирает информацию от провайдерского dns, и переключает работоспособность сайта (скорее всего это глюк их алгоритма), в зависимости от того, когда был запрос к локальному dns
Яхз, может и костыль, но работает. Тут обратил внимание, что почему-то версия с www нормально грузится. Сделал в nginx редиректы на www.sitename.domain и все пашет. Что это и почему так - не понимаю. Еще на всякий случай пересадил сайт на отдельный ip, а то у меня на сервере и сайт и VLESS с редиректом дальше зарубеж
Проходили такое. <br/> http2 в nginx config надо добавить, синтаксис смотрите в сети
Похожие вопросы