From 5d508110e18f1c0aaa0d7b2a68b91ad335377954 Mon Sep 17 00:00:00 2001 From: "E.Gavrilov" Date: Fri, 4 Sep 2026 01:28:06 +0300 Subject: [PATCH] =?UTF-8?q?editorial-364:=20=D1=83=D0=BB=D1=83=D1=87=D1=88?= =?UTF-8?q?=D0=B8=D1=82=D1=8C=20=D1=81=D1=82=D0=B0=D1=82=D1=8C=D1=8E=20?= =?UTF-8?q?=D0=BE=20=D1=82=D0=B0=D0=B9=D0=BC=D0=B0=D1=83=D1=82=D0=B5=20Fir?= =?UTF-8?q?efox?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- editorial/agent-rewrites/364.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/editorial/agent-rewrites/364.json b/editorial/agent-rewrites/364.json index 2d4b5e2..adf998d 100644 --- a/editorial/agent-rewrites/364.json +++ b/editorial/agent-rewrites/364.json @@ -3,5 +3,5 @@ "slug": "firefox-увеличение-ожидания-загрузки-timeout-стр", "title": "Firefox и долгий HTTP-запрос: как увеличить timeout, не скрыв неисправность", "excerpt": "Если Firefox обрывает долгий запрос, сначала определите этап задержки. Затем временно измените response timeout в отдельном профиле и проверьте, что запрос действительно продолжает работу.", - "contentHtml": "

Страница в Firefox долго остаётся пустой, а затем появляется сообщение о сетевой ошибке. Вы повторяете запрос, видите тот же обрыв и меняете первый найденный параметр в about:config. Ошибка исчезает не всегда. Иногда браузер просто ждёт дольше, пока сервер, прокси или балансировщик всё равно не закроет соединение.

\\n

Цена такого решения — потерянное время и ложное чувство исправности. Администратор может повторить импорт, отчёт или выгрузку и получить вторую операцию. Пользователь может принять долгий белый экран за норму. Если запрос меняет данные, повторение повышает риск дубликатов. Увеличение таймаута не ускоряет сервер и не делает операцию надёжнее само по себе.

\n

Тезис статьи простой: меняйте таймаут Firefox только после того, как установили место задержки. Параметр network.http.response.timeout ограничивает ожидание HTTP-ответа на стороне браузера. Он не отменяет ограничения приложения, веб-сервера, reverse proxy, балансировщика, VPN или сети. Для разовой диагностики настройка полезна. Для обычного пользовательского сценария она почти всегда указывает на задачу для серверной архитектуры.

\n
\"Песочные
Иллюстрация показывает ожидание ответа. Само ожидание ещё не объясняет, какой слой задерживает запрос.
\n

Что именно ждёт Firefox

\n

Слово timeout описывает несколько разных пределов. Браузер может ждать DNS-ответ, установления TCP-соединения, TLS-рукопожатия, первого байта HTTP-ответа или оставшихся байтов тела. Эти этапы имеют разные причины и разные владельцы. Ошибка при соединении не лечится тем же параметром, что пауза перед первым байтом.

\n

В Firefox откройте DevTools сочетанием Ctrl+Shift+E или через меню разработчика и включите вкладку Network. Перезагрузите страницу с открытой панелью. Выберите проблемный запрос. В разделе Timings смотрите DNS Lookup, Connecting, TLS Setup, Waiting и Receiving. Названия и детализация могут отличаться по версии, но принцип сохраняется: сначала зафиксируйте этап, потом выбирайте гипотезу.

\n

Длинное Waiting обычно означает высокий TTFB: сервер получил запрос, но долго готовит первый байт. Причиной могут быть SQL-запрос, построение отчёта, обращение к внешнему API или блокировка. Длинное Receiving означает, что ответ уже начался, но тело передаётся медленно. Обрыв до ответа чаще связан с сетью, прокси, перегрузкой или лимитом соединения. Это не строгий диагноз, а способ сузить поиск.

\n

Сохраните HAR или хотя бы время начала, URL без секретов, статус, размер ответа и значения Timings. Не публикуйте cookies, токены и персональные параметры из HAR. Один скриншот ошибки не показывает, что произошло с запросом. Нужна запись конкретного этапа.

\n

Механизм на примере

\n

Представим учебный endpoint https://example.test/report. Он строит отчёт и отдаёт первый байт через 420 секунд. Firefox имеет локальный response timeout 300 секунд. Браузер завершит ожидание раньше ответа. Временное значение 600 секунд даст серверу шанс прислать результат. Это только учебный пример. Он не доказывает, что любой отчёт должен работать 420 секунд, и не является результатом измерений в production.

\n
# Учебная проверка. Не вставляйте секреты в командную строку.\ncurl --verbose --max-time 600 --output /tmp/report.out https://example.test/report\n\n# Если endpoint требует авторизацию, используйте безопасный способ\n# передачи заголовков и удалите файл после локальной проверки.
\n

Команда нужна не для замены Firefox. Она помогает отделить проблему браузерного профиля от проблемы URL или сервера. Если curl также ждёт 420 секунд и завершается на лимите, менять Firefox первым не стоит. Если curl получает ответ быстро, а Firefox обрывает запрос, сравните профиль, расширения, прокси, кеш и параметры браузера.

\n

При HTTP-ответе сервер может отправить заголовки, статус и часть тела, а затем долго продолжать передачу. В таком сценарии важен не только response timeout. Проверьте лимиты на размер ответа, idle timeout и время жизни соединения на промежуточных узлах. Если приложение отправляет данные порциями, прокси может считать соединение активным; если приложение молчит, прокси может закрыть его раньше браузера.

\n
Диагностика по наблюдаемому симптому
СимптомВероятная причинаПроверкаДействие
Долгое Waiting до первого байтаПриложение, база данных или внешний APIСравнить TTFB, серверный trace и логиОптимизировать запрос или вынести работу в фон
Соединение закрывает проксиIdle или upstream timeoutСверить конфигурацию всех промежуточных узловСогласовать лимиты и добавить наблюдение
Только один профиль Firefox не загружает URLЛокальная настройка, расширение или кешПовторить в чистом профиле и без расширенийСбросить изменённую настройку, затем проверить снова
curl и Firefox завершаются одинаковоСервер, сеть или общий проксиСнять логи и повторить запрос из той же сетиИсправлять общий слой, не браузер
Ответ начался, но тело не заканчиваетсяМедленная выдача, большой ответ или разрыв потокаСмотреть Receiving, размер и серверные лимитыПроверить потоковую выдачу, размер и idle timeout
\n

Как временно изменить настройку

\n

Параметры about:config относятся к профилю Firefox. Mozilla предупреждает, что расширенные настройки могут повлиять на стабильность, безопасность и производительность. Поэтому не меняйте значение в основном профиле без записи исходного состояния. Для диагностики создайте отдельный профиль или заранее сохраните старое значение.

\n

В исходном коде Firefox для network.http.response.timeout указано значение 300 секунд. Это не обещание для всех выпусков: настройки Firefox могут меняться. В вашей версии значение может отсутствовать, быть переопределено политикой или работать иначе в конкретном сетевом сценарии. Проверяйте фактическую строку и версию браузера.

\n
  1. Зафиксируйте URL, время запроса, этап задержки и исходное значение параметра. Удалите секреты из заметки.
  2. Повторите запрос в Network Monitor, затем тем же URL выполните ограниченную учебную проверку через другой HTTP-клиент.
  3. Сверьте таймауты приложения, веб-сервера, reverse proxy, балансировщика и внешних зависимостей. Найдите минимальный предел, который может закрыть соединение.
  4. Откройте в Firefox страницу about:config. Примите предупреждение только в профиле, предназначенном для диагностики.
  5. Найдите network.http.response.timeout. Измените значение в секундах на небольшой срок, достаточный для проверки гипотезы, например 600 для учебного сценария.
  6. Повторите тот же запрос с теми же входными данными. Сравните этапы Timings, статус, размер ответа и серверный лог.
  7. После проверки верните исходное значение или нажмите Reset у изменённого предпочтения. Повторите запрос и убедитесь, что профиль не сохранил лишнюю настройку.
\n

Не отключайте таймаут полностью. Бесконечное ожидание удерживает вкладку и сетевые ресурсы, затрудняет отмену и прячет отказ. Не ставьте несколько часов только потому, что операция однажды работала дольше минуты. Значение должно следовать из измеренного верхнего предела и запаса, а не из случайного числа.

\n

Когда настройка не подходит

\n

Если отчёт или импорт занимает минуты, браузерный запрос уже плохо подходит для пользовательского интерфейса. Серверу лучше принять задачу, вернуть идентификатор и выполнять работу в очереди. Клиент затем опрашивает статус или получает событие о завершении. Такой путь показывает прогресс, допускает повторную загрузку страницы и отделяет жизненный цикл задачи от вкладки.

\n

Для операций, которые меняют данные, одного увеличения timeout недостаточно. Браузер может не узнать, успел ли сервер сохранить запись до обрыва соединения. Повторный клик может создать дубликат. Используйте идемпотентный ключ операции, журнал состояния и явный способ узнать результат. Эти меры относятся к приложению, а не к Firefox.

\n

Если проблема возникает только в корпоративной сети, сравните прямой доступ и путь через прокси только с разрешения владельца сети. Не обходите политики безопасности и не меняйте TLS-проверки ради долгого запроса. Если сбой связан с DNS, VPN или маршрутом, response timeout не исправит доставку.

\n

Если параметр не найден, не создавайте его автоматически. Сначала проверьте версию Firefox, политику управления браузером и документацию к вашему выпуску. Создание неизвестного предпочтения может ничего не изменить и создаёт ложный след диагностики.

\n

Проверяемый критерий готовности

\n

Диагностика завершена, когда вы можете назвать этап задержки, владельца этого этапа и предел, который закрывал соединение. Тот же запрос должен воспроизводимо пройти в выбранном тестовом профиле. В Network Monitor должны совпасть ожидаемый статус, TTFB или время передачи, размер ответа и финальный результат. Серверный лог должен содержать соответствующую операцию.

\n

Для временной настройки добавьте ещё два условия: исходное значение записано, а после проверки оно восстановлено. Если исправление требует постоянного увеличения таймаута для всех пользователей, оформите его на стороне приложения и инфраструктуры с измерением, лимитом и планом отмены. Изменение about:config в личном профиле не считается исправлением production-проблемы.

\n

Проверяемые источники

\n" + "contentHtml": "

Страница в Firefox долго остаётся пустой, а затем появляется сообщение о сетевой ошибке. Вы повторяете запрос, видите тот же обрыв и меняете первый найденный параметр в about:config. Ошибка исчезает не всегда: браузер может ждать дольше, пока сервер, прокси или балансировщик всё равно не закроет соединение.

\n

Цена такого решения — потерянное время и ложное чувство исправности. Администратор может повторить импорт, отчёт или выгрузку и получить вторую операцию. Если запрос меняет данные, повторение повышает риск дубликатов. Увеличение таймаута не ускоряет сервер и не делает операцию надёжнее само по себе.

\n

Меняйте таймаут Firefox только после того, как установили место задержки. Настройка network.http.response.timeout относится к ожиданию начального HTTP-ответа: в исходниках Firefox она описана как предел, после которого соединение закрывается, если начальный ответ не пришёл. Она не отменяет ограничения приложения, веб-сервера, reverse proxy, балансировщика, VPN или сети. Для разовой диагностики настройка полезна, а для обычного пользовательского сценария указывает на задачу для серверной архитектуры.

\n
Песочные часы рядом с окном Firefox и индикатором ожидания ответа
Иллюстрация показывает ожидание ответа. Само ожидание ещё не объясняет, какой слой задерживает запрос.
\n

Что именно ждёт Firefox

\n

Слово timeout описывает несколько разных пределов. Браузер может ждать DNS-ответ, установления TCP-соединения, TLS-рукопожатия, первого байта HTTP-ответа или оставшихся байтов тела. Эти этапы имеют разные причины и разные владельцы. Ошибка при соединении не лечится тем же параметром, что пауза перед первым байтом.

\n

В Firefox откройте DevTools сочетанием Ctrl+Shift+E или через меню разработчика и выберите вкладку Network. Перезагрузите страницу с открытой панелью. Выберите проблемный запрос и откройте Timings. Смотрите DNS Lookup, Connecting, TLS Setup, Waiting и Receiving. Названия и детализация могут отличаться по версии, но порядок проверки сохраняется: сначала зафиксируйте этап, затем выбирайте гипотезу.

\n

Длинное Waiting обычно означает высокий TTFB: сервер получил запрос, но долго готовит первый байт. Причиной могут быть SQL-запрос, построение отчёта, обращение к внешнему API или блокировка. Длинное Receiving означает, что ответ уже начался, но тело передаётся медленно. Обрыв до ответа чаще связан с сетью, прокси, перегрузкой или лимитом соединения. Это способ сузить поиск, а не строгий диагноз.

\n

Сохраните HAR или хотя бы время начала, URL без секретов, статус, размер ответа и значения Timings. Не публикуйте cookies, токены и персональные параметры из HAR. Один скриншот ошибки не показывает, что произошло с запросом. Нужна запись конкретного этапа.

\n

Сценарий: задержка до первого байта

\n

Представим локальный учебный endpoint. Файл report.php ждёт пять секунд и только после этого отправляет заголовки и тело. В тестовом профиле Firefox временно установлено значение 3 для network.http.response.timeout. Браузер завершит ожидание раньше начального ответа. После увеличения значения до 10 секунд тот же запрос получит шанс закончиться. Это лабораторная проверка механизма, а не измерение production-сервера.

\n
<?php\nsleep(5);\nheader('Content-Type: text/plain; charset=utf-8');\necho 'ok\\n';
\n
php -S 127.0.0.1:8080\ncurl --verbose --max-time 10 --output /tmp/report.out http://127.0.0.1:8080/report.php
\n

Сохраните первый фрагмент как report.php, запустите локальный PHP-сервер в той же папке и откройте URL в тестовом профиле. Команда curl помогает сравнить другой HTTP-клиент с Firefox; параметр --max-time ограничивает всю операцию клиента. Если оба клиента ждут пять секунд и получают ответ, причина, вероятно, связана с профилем Firefox. Если оба завершаются раньше, проверяйте общий слой. После этого остановите локальный сервер.

\n

При HTTP-ответе сервер может отправить заголовки, статус и часть тела, а затем долго продолжать передачу. В таком сценарии важен не только response timeout. Проверьте лимиты на размер ответа, idle timeout и время жизни соединения на промежуточных узлах. Если приложение отправляет данные порциями, прокси может считать соединение активным; если приложение молчит, прокси может закрыть его раньше браузера.

\n
Диагностика по наблюдаемому симптому
СимптомВероятная причинаПроверкаДействие
Долгое Waiting до первого байтаПриложение, база данных или внешний APIСравнить TTFB, серверный trace и логиОптимизировать запрос или вынести работу в фон
Соединение закрывает проксиIdle или upstream timeoutСверить конфигурацию всех промежуточных узловСогласовать лимиты и добавить наблюдение
Только один профиль Firefox не загружает URLЛокальная настройка, расширение или кешПовторить в чистом профиле и без расширенийСбросить изменённую настройку, затем проверить снова
curl и Firefox завершаются одинаковоСервер, сеть или общий проксиСнять логи и повторить запрос из той же сетиИсправлять общий слой, не браузер
Ответ начался, но тело не заканчиваетсяМедленная выдача, большой ответ или разрыв потокаСмотреть Receiving, размер и серверные лимитыПроверить потоковую выдачу, размер и idle timeout
\n

Как временно изменить настройку

\n

Параметры about:config относятся к профилю Firefox. Mozilla предупреждает, что расширенные настройки могут повлиять на стабильность, безопасность и производительность. Поэтому не меняйте значение в основном профиле без записи исходного состояния. Для диагностики создайте отдельный профиль или заранее сохраните старое значение.

\n

В текущем исходном коде Firefox для network.http.response.timeout указано значение 300 секунд, а комментарий уточняет, что речь идёт о неполучении начального ответа. Это снимок текущей ветки исходников, а не обещание для любого выпуска и не доказательство того, какое значение было в старой версии. В вашей версии preference может отсутствовать, быть переопределён политикой или вести себя иначе в конкретном сетевом сценарии. Проверяйте фактическую строку, версию браузера и профиль.

\n
  1. Зафиксируйте URL, время запроса, этап задержки и исходное значение параметра. Удалите секреты из заметки.
  2. Повторите запрос в Network Monitor, затем тем же URL выполните ограниченную проверку через другой HTTP-клиент.
  3. Сверьте таймауты приложения, веб-сервера, reverse proxy, балансировщика и внешних зависимостей. Найдите минимальный предел, который может закрыть соединение.
  4. Откройте в Firefox страницу about:config. Примите предупреждение только в профиле, предназначенном для диагностики.
  5. Найдите network.http.response.timeout. Имена preferences чувствительны к регистру. Измените значение в секундах на небольшой срок, достаточный для проверки гипотезы, например 10 для локального сценария.
  6. Повторите тот же запрос с теми же входными данными. Сравните этапы Timings, статус, размер ответа и серверный лог.
  7. После проверки верните исходное значение или нажмите Reset у изменённого preference. Повторите запрос и убедитесь, что профиль не сохранил лишнюю настройку.
\n

Не отключайте таймаут полностью. Бесконечное ожидание удерживает вкладку и сетевые ресурсы, затрудняет отмену и прячет отказ. Не ставьте несколько часов только потому, что операция однажды работала дольше минуты. Значение должно следовать из измеренного верхнего предела и запаса, а не из случайного числа.

\n

Когда настройка не подходит

\n

Если отчёт или импорт занимает минуты, браузерный запрос уже плохо подходит для пользовательского интерфейса. Серверу лучше принять задачу, вернуть идентификатор и выполнять работу в очереди. Клиент затем опрашивает статус или получает событие о завершении. Такой путь показывает прогресс, допускает повторную загрузку страницы и отделяет жизненный цикл задачи от вкладки.

\n

Для операций, которые меняют данные, одного увеличения timeout недостаточно. Браузер может не узнать, успел ли сервер сохранить запись до обрыва соединения. Повторный клик может создать дубликат. Используйте идемпотентный ключ операции, журнал состояния и явный способ узнать результат. Эти меры относятся к приложению, а не к Firefox.

\n

Если проблема возникает только в корпоративной сети, сравните прямой доступ и путь через прокси только с разрешения владельца сети. Не обходите политики безопасности и не меняйте TLS-проверки ради долгого запроса. Если сбой связан с DNS, VPN или маршрутом, response timeout не исправит доставку.

\n

Если preference не найден, не создавайте его автоматически для рабочей задачи. Сначала проверьте версию Firefox, политику управления браузером и документацию к вашему выпуску. Создание неизвестного preference может ничего не изменить и создаёт ложный след диагностики.

\n

Проверяемый критерий готовности

\n

Диагностика завершена, когда вы можете назвать этап задержки, владельца этого этапа и предел, который закрывал соединение. Тот же запрос должен воспроизводимо пройти в выбранном тестовом профиле. В Network Monitor должны совпасть ожидаемый статус, TTFB или время передачи, размер ответа и финальный результат. Серверный лог должен содержать соответствующую операцию.

\n

Для временной настройки добавьте ещё два условия: исходное значение записано, а после проверки оно восстановлено. Если исправление требует постоянного увеличения таймаута для всех пользователей, оформите его на стороне приложения и инфраструктуры с измерением, лимитом и планом отмены. Изменение about:config в личном профиле не считается исправлением production-проблемы.

\n

Проверяемые источники

\n" }