firefox слеит за сетевыми интерфейсами, как отключить?

Добавить в /etc/hosts:

0.0.0.0 detectportal.firefox.com

Запрос этот не мешает, дело не в нём. Перечитай тему.

about:config

network.captive-portal-service.enabled

Пожалуй это оно

как и хром

это не для авторизации в публичных сетях шняга разве?

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

FirefoxDetectportal.firefox.com используется для обнаружения подключения к адаптивному порталу. Captive-портал — это веб-страница, обычно используемая в общедоступных сетях Wi-Fi, которая требует от пользователей пройти аутентификацию или принять условия обслуживания, прежде чем они смогут получить доступ к Интернету.

Когда пользователь пытается открыть веб-страницу в браузере Firefox, Firefox сначала перенаправляет запрос на сайтDetectportal.firefox.com. Эта страница возвращает специальный ответ, который указывает, находится ли пользователь на портале авторизации или нет. На основании этого ответа Firefox может затем перенаправить пользователя на страницу входа в авторизованный портал или разрешить ему доступ в Интернет.

Итак, Detectportal.firefox.com — это механизм, который позволяет Firefox обнаруживать авторизованные порталы и улучшать взаимодействие с пользователем в общедоступных сетях Wi-Fi.

Ещё раз - проблема не в портале, а в том, что фф как-то узнаёт про интерфейсы и пытается что-то предпринимать. Самое вредное из того, что он делает - это удаляет текущие ждущие запросы к сайтам (видимо, рассчитывая что раз инета нет то и ждать их незачем, только вот ответ ему присылается не инетом а локальной проксей).

detectportal (как и вообще *.firefox.com *.mozilla.org *.mozilla.com в рамках борьбы с телеметрией и удалённой сменой конфигов) давно заблочено и так.

Он dbus палит скорее всего

Это неотключаемое поведение. Хром поступает точно так же.

видимо, рассчитывая что раз инета нет то и ждать их незачем,

Логика в другом. У вас поменялись сетевые интерфейсы, по которым производился запрос. Браузер не знает, что у вас за передачу данных отвечает внешний прокси.

Пример: у меня есть рабочий ВПН, который включен только для ресурсов сети, за которые он отвечает (например 15.0.х.х). Предположим, что я зашел на сайт такого ресурса с выключенным ВПН. Браузер пытается произвести запрос (безуспешно). Я включаю ВПН. Браузер получает информацию, что сетевой интерфейс, отвечающий за доступ к такому ресурсу изменился. Он обрывает все текущие соединения (но только для ресурсов этой подсети) и подключается заново (успешно).

Зачем это нужно: если не обрывать такие соединения, а ресурс доступен и вне сети (но другой ресурс) то у вас возникает путаница - какой запрос полетит на какой ресурс. Например браузер запросил картинку из википедии связанную с площадью Тианмен. Там изображен человек на площади. Вы включаете ВПН, старая картинка догружается вместо отцензуренной версии, получилось картинка с человеком и подписью «тут ничего не было».

Логика в другом. У вас поменялись сетевые интерфейсы, по которым производился запрос. Браузер не знает, что у вас за передачу данных отвечает внешний прокси.

Ну это странная логика и более того с фактическими ошибками.

Во-первых, соответствие tcp-соединений и сетевых интерфейсов - это зона ответственности ОС (ОС может прислать destination unreachable или что-то аналогичное и дропнуть коннект, если он пытается слать пакеты в отключённый интерфейс). Во-вторых, браузер как раз прекрасно знает, что коннекты идут на 127.0.0.10 на интерфейсе lo, это указано в его же настройках.

Он обрывает все текущие соединения (но только для ресурсов этой подсети) и подключается заново (успешно).

Это уже выглядит логичнее, но думаю он даже не пытается выяснять в какой интерфейс что шлётся, а просто перезапускает все. Но в данном случае не перезапускает а просто как бы забывает, что был нажат переход по линку или отправка формы. Возможно, это (про забывание) баг, но было бы лучше если он вообще не обращал внимания на конфигурацию сети ОС.