так как интенсивность ошибок сильно возросла - поймал ошибку явно в консоли браузера - это NS_ERROR_NET_INTERRUPT
chatGPT дает такую инструкцию
------------------------------
[center]
Диагностика ошибки NS_ERROR_NET_INTERRUPT[/center]
Что означает ошибка
Ошибка
в Firefox означает, что соединение с сервером было установлено, но передача данных неожиданно прервалась.
Это обычно не проблема DNS и не обычная HTTP-ошибка вида 404 или 500. Браузер начал получать ответ, но сервер, прокси, CDN или backend закрыл соединение до завершения передачи данных.
Если ошибка возникает у нескольких посетителей, проверять нужно:
- веб-сервер;
- reverse proxy;
- CDN или Cloudflare;
- PHP-FPM, Node.js, Java или другой backend;
- нагрузку и ресурсы сервера;
- IPv4 и IPv6;
- HTTP/2 и HTTP/3;
- таймауты;
- целостность HTTP-ответа.
1. Определить, какой именно запрос завершается ошибкой
В Firefox открыть:
Затем обновить проблемную страницу.
Нужно посмотреть:
- падает основной HTML-документ или отдельный CSS, JS, изображение либо API-запрос;
- точный URL запроса;
- используемый протокол: HTTP/1.1, HTTP/2 или HTTP/3;
- IP-адрес сервера;
- размер уже полученной части ответа;
- ошибка возникает сразу или спустя фиксированное время;
- падают только динамические страницы или также статические файлы.
Желательно сохранить HAR-файл:
Код: Выделить всё
Правая кнопка в списке запросов → Save All As HAR
Если падает только один API-запрос, проблему нужно искать прежде всего в приложении или backend.
Если прерывается загрузка основного HTML-документа, возможны проблемы с Nginx, Apache, CDN, балансировщиком или перезапуском backend.
2. Сравнить HTTP/1.1 и HTTP/2
С Linux-сервера или другой машины выполнить:
Код: Выделить всё
URL='https://example.com/problem-page'
curl -vk --http1.1 "$URL" -o /dev/null
curl -vk --http2 "$URL" -o /dev/null
Для многократной проверки:
Код: Выделить всё
URL='https://example.com/problem-page'
for proto in '--http1.1' '--http2'; do
echo "=== $proto ==="
```
for i in $(seq 1 100); do
curl -sS "$proto" \
--connect-timeout 10 \
--max-time 60 \
-o /dev/null \
-w "$i code=%{http_code} ip=%{remote_ip} bytes=%{size_download} time=%{time_total}\n" \
"$URL" ||
echo "$i FAILED rc=$?"
done
```
done
Особенно важны коды завершения curl:
- — сервер передал меньше данных, чем обещал;
- — сервер закрыл соединение, не вернув ответ;
- — ошибка получения данных, часто TCP reset;
- — ошибка HTTP/2-потока.
Если HTTP/1.1 работает стабильно, а HTTP/2 периодически завершается ошибкой, нужно проверять:
- настройки HTTP/2;
- CDN;
- TLS-терминатор;
- reverse proxy;
- связь proxy с backend.
Если включён HTTP/3, его желательно временно отключить и повторить тест.
3. Одновременно смотреть журналы сервера
Во время воспроизведения ошибки нужно наблюдать за журналами веб-сервера и backend.
Nginx
Код: Выделить всё
tail -F /var/log/nginx/access.log /var/log/nginx/error.log
Искать сообщения:
Код: Выделить всё
upstream prematurely closed connection
recv() failed
connection reset by peer
upstream timed out
no live upstreams
worker_connections are not enough
open socket ... left in connection
Код: Выделить всё
tail -F /var/log/httpd/access_log /var/log/httpd/error_log
Код: Выделить всё
tail -F /var/log/apache2/access.log /var/log/apache2/error.log
В некоторых конфигурациях:
Искать сообщения:
Код: Выделить всё
server reached pm.max_children
child exited on signal
segmentation fault
request terminated
execution timed out
Важно сопоставить точное время ошибки в браузере с записями:
- access.log;
- error.log;
- PHP-FPM;
- журналом приложения;
- системным журналом.
Если запрос появился в access.log, но размер ответа необычно маленький, вероятно, соединение оборвалось после начала передачи страницы.
4. Проверить перезапуски и нехватку ресурсов
Проверить OOM, аварии процессов и перезапуски:
Код: Выделить всё
journalctl --since "2 hours ago"
| egrep -i 'oom|out of memory|killed process|segfault|core dumped|restart|failed'
journalctl -k --since "2 hours ago"
| egrep -i 'oom|killed process|segfault|conntrack|reset'
Проверить текущее состояние сервера:
Проверить сервисы:
Код: Выделить всё
systemctl status nginx
systemctl status httpd
systemctl status apache2
systemctl status php-fpm
Проверить историю перезапусков:
Код: Выделить всё
journalctl -u nginx --since today
journalctl -u php-fpm --since today
Если сайт работает в Docker:
Код: Выделить всё
docker ps -a
docker stats
docker inspect --format='{{.Name}} restarts={{.RestartCount}}' $(docker ps -aq)
Частая причина ошибки: PHP-FPM, Node.js, Java или контейнер завершается по OOM либо перезапускается уже после того, как веб-сервер начал отдавать ответ пользователю.
Также обязательно проверить:
- свободную оперативную память;
- swap;
- свободное место на диске;
- количество inode;
- нагрузку CPU;
- количество соединений;
- лимиты процессов и файловых дескрипторов.
5. Проверить таймауты Nginx и reverse proxy
Показать активную конфигурацию:
Код: Выделить всё
nginx -T 2>&1 | grep -E
'proxy_(connect|read|send)_timeout|fastcgi_read_timeout|send_timeout|keepalive|http2|http3'
Особенно проверить:
Код: Выделить всё
proxy_connect_timeout
proxy_read_timeout
proxy_send_timeout
fastcgi_read_timeout
send_timeout
keepalive_timeout
Если ошибка появляется примерно через 30, 60 или 100 секунд, это важный признак таймаута.
Не следует сразу увеличивать все таймауты. Сначала нужно понять, почему backend перестаёт передавать данные.
Для PHP-FPM проверить:
Код: Выделить всё
php-fpm -tt 2>&1 | grep -E
'pm.max_children|request_terminate_timeout|request_slowlog_timeout'
Проверить PHP:
Код: Выделить всё
php -i | grep -E 'max_execution_time|memory_limit'
Особенно важны:
Если в журнале есть:
значит PHP-FPM не успевает обслуживать все запросы, и нужно проверять нагрузку, медленные запросы и конфигурацию пула.
6. Проверить Apache
Показать конфигурацию Apache:
Найти основные параметры:
Код: Выделить всё
grep -R -E
'^(TimeOut|ProxyTimeout|KeepAlive|KeepAliveTimeout|MaxKeepAliveRequests)'
/etc/httpd /etc/apache2 2>/dev/null
Проверить:
- ;
- ;
- ;
- ;
- ;
- лимиты MPM;
- количество занятых worker-процессов.
Если Apache работает как reverse proxy, нужно проверить соединения с backend и повторное использование уже закрытых backend-соединений.
7. Проверить CDN, Cloudflare или балансировщик
Если перед сайтом используется Cloudflare, CDN, HAProxy, Nginx Proxy Manager, AWS ALB или другой балансировщик, нужно сравнить работу через CDN и напрямую с origin-сервером.
Пример:
- домен: ;
- реальный IP origin: .
Проверка напрямую:
Код: Выделить всё
curl -vk
--resolve site.example.com:443:192.0.2.10
https://site.example.com/problem-page
-o /dev/null
Многократная проверка:
Код: Выделить всё
for i in $(seq 1 100); do
curl -sS
--resolve site.example.com:443:192.0.2.10
--connect-timeout 10
--max-time 60
-o /dev/null
-w "$i code=%{http_code} bytes=%{size_download} time=%{time_total}\n"
https://site.example.com/problem-page ||
echo "$i FAILED rc=$?"
done
Интерпретация результата:
- напрямую origin работает стабильно, а через CDN падает — проблема в CDN, WAF, HTTP/2, HTTP/3 или связи CDN с origin;
- ошибка возникает и напрямую, и через CDN — проблема на origin-сервере или в backend;
- origin падает только иногда — проверить несколько backend-серверов, перезапуски и ресурсы;
- ошибка возникает только на одном узле — один сервер балансировщика неисправен или настроен иначе.
Также нужно проверить журналы Cloudflare или другого CDN, если тариф предоставляет такую возможность.
8. Проверить IPv4 и IPv6
Посмотреть DNS-записи:
Код: Выделить всё
dig +short A site.example.com
dig +short AAAA site.example.com
Сравнить IPv4 и IPv6:
Код: Выделить всё
curl -4 -vk https://site.example.com/ -o /dev/null
curl -6 -vk https://site.example.com/ -o /dev/null
Если IPv4 работает, а IPv6 падает, возможны следующие причины:
- неправильная AAAA-запись;
- по IPv6 запрос попадает на другой сервер;
- Firewall некорректно обрабатывает IPv6;
- Nginx или Apache слушает IPv6 с другой конфигурацией;
- у IPv6-сервера неправильный сертификат;
- на IPv6 используется другой backend;
- есть проблема с MTU или маршрутизацией.
Если у домена несколько IP-адресов, каждый нужно проверить отдельно:
Код: Выделить всё
curl -vk
--resolve site.example.com:443:IP_КОНКРЕТНОГО_СЕРВЕРА
https://site.example.com/
-o /dev/null
Если один из нескольких серверов неисправен, ошибка для пользователей будет возникать случайно.
9. Проверить целостность HTTP-ответа
Сохранить заголовки и тело ответа:
Код: Выделить всё
curl -vk --compressed
-D /tmp/headers.txt
-o /tmp/body.bin
https://site.example.com/problem-page
cat /tmp/headers.txt
wc -c /tmp/body.bin
Обратить внимание на заголовки:
Код: Выделить всё
Content-Length
Transfer-Encoding: chunked
Content-Encoding: gzip
Content-Encoding: br
Connection
Возможные проблемы:
- сервер указал Content-Length, но передал меньше байтов;
- backend закрыл chunked-ответ до его завершения;
- PHP или приложение начало вывод страницы, а затем аварийно завершилось;
- неправильно работает gzip или Brotli;
- CDN сохранил повреждённый объект в кеше;
- reverse proxy разорвал соединение во время передачи;
- приложение отправило некорректные HTTP-заголовки.
Проверка без сжатия:
Код: Выделить всё
curl -vk
-H 'Accept-Encoding: identity'
https://site.example.com/problem-page
-o /dev/null
Если без gzip или Brotli ошибка исчезает, нужно проверить:
- модуль сжатия веб-сервера;
- настройки CDN;
- кеш CDN;
- двойное сжатие;
- формирование Content-Length.
10. Проверить сетевые сбросы и Firewall
Проверить таблицу соединений:
Проверить conntrack:
Код: Выделить всё
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
Проверить сообщения ядра:
Код: Выделить всё
dmesg -T | egrep -i 'conntrack|drop|reset|oom|network|tcp'
Если используется firewalld:
Код: Выделить всё
firewall-cmd --list-all
firewall-cmd --list-all-zones
Если используется nftables:
Если используется iptables:
Для точной диагностики TCP-сбросов можно временно запустить:
Код: Выделить всё
tcpdump -ni any host IP_КЛИЕНТА and port 443
Либо записать дамп:
Код: Выделить всё
tcpdump -ni any port 443 -w /tmp/site-443.pcap
Затем посмотреть, кто именно отправляет TCP RST:
- клиент;
- веб-сервер;
- reverse proxy;
- балансировщик;
- Firewall;
- провайдер.
11. Рекомендуемый порядок диагностики
Проверять лучше в следующем порядке:
- Найти точный падающий URL в Firefox Network.
- Определить, падает HTML-документ или отдельный API-запрос.
- Запустить 100 запросов через curl.
- Сравнить HTTP/1.1 и HTTP/2.
- Одновременно открыть журналы Nginx, Apache и backend.
- Проверить OOM, перезапуски, свободную память и диск.
- Сравнить IPv4 и IPv6.
- Сравнить обращение через CDN и напрямую к origin.
- Проверить, возникает ли ошибка через фиксированное время.
- Проверить Content-Length, chunked transfer, gzip и Brotli.
- Проверить все серверы, если у домена несколько IP-адресов.
- При необходимости снять tcpdump.
12. Какие данные собрать для дальнейшего анализа
Для точного поиска причины желательно собрать:
- домен сайта;
- точный URL проблемной страницы;
- HAR-файл из браузера;
- время возникновения ошибки с точностью до минуты;
- результаты curl для HTTP/1.1 и HTTP/2;
- код завершения curl;
- 20–30 строк error.log за момент ошибки;
- строку из access.log;
- логи PHP-FPM или другого backend;
- результат проверки IPv4 и IPv6;
- схему сайта, например:
или:
или:
Код: Выделить всё
Cloudflare → HAProxy → несколько backend-серверов
Также полезно указать:
- используется ли Docker;
- есть ли несколько серверов;
- используется ли HTTP/3;
- возникает ли ошибка только у Firefox или также у Chrome;
- какие страницы падают чаще всего;
- происходит ли это во время высокой нагрузки.
[center]
Наиболее вероятные причины[/center]
- перезапуск или авария PHP-FPM/backend;
- нехватка оперативной памяти и OOM;
- достижение pm.max_children;
- таймаут reverse proxy;
- ошибка HTTP/2 или HTTP/3;
- неисправный сервер среди нескольких backend;
- проблема IPv6;
- обрыв ответа при gzip или Brotli;
- неправильный Content-Length;
- сброс соединения Firewall, CDN или балансировщиком;
- переполнение conntrack;
- заполненный диск или отсутствие inode.
Главное — не менять настройки вслепую, а сначала определить, на каком участке прерывается соединение:
Код: Выделить всё
Браузер → CDN → reverse proxy → веб-сервер → backend → база данных
