Хотелось бы понять куда копать. Проверил на другой машине в той же сети (Firefox 69.0 64-bit, Windows 7 64-bit) - неблокированные ресурсы при включении proxy.pac также лагают исключительно в Firefox.

Методика тестирования:

  1. Отключаем proxy.pac в настройках Firefox
  2. Открываем приватное окно
  3. Включаем сетевой монитор Firefox из инструментов разработчика
  4. Загружаем неблокированный url и дожидаемся полной загрузки
  5. Записываем время DOMContentLoaded и load
  6. Закрываем приватное окно
  7. Включаем proxy.pac в настройках прокси
  8. Открываем приватное окно и повторяем шаги с 3 по 5

Результаты.

Proxy.pac отключен:

https://habr.com/ru/post/472780/
DOMContentLoaded: 7,44 с
load: 9,04 с

https://irecommend.ru/
DOMContentLoaded: 2,99 с
load: 4,75 с

Proxy.pac включен:

https://habr.com/ru/post/472780/
DOMContentLoaded: 17,60 с
load: 29,57 с

https://irecommend.ru/
DOMContentLoaded: 48,40 с
load: 1,24 мин

Попробуйте так:

  1. Скачать свежий PAC-скрипт (проделать обязательно).
  2. Модифицировать в нём строчку, которая может вызывать замедление. Для начала можно заменить dnsResolve(...) на null и проверить, в DNS ли проблема.
  3. Настроить FireFox на загрузку модифицированного скрипта из файловой системы или с localhost.

Благодарю, помогло. Заменил dnsResolve(…) на dnsResolve(null). Незаблокированные сайты загружаются без лагов, заблокированные тоже перестали лагать. Мой провайдер фильтрует по ip, поэтому резолвить имена через серверы Антизапрета это лишний overhead. Непонятно почему вебкит не ломается когда dnsResolve не выставлен в (null). Я так понимаю нельзя глобально выставить dnsResolve в (null), так как это сломает всё у пользователей чьи провайдеры подменяют ответы DNS?

Проверки одного лишь доменного имени недостаточно, чтобы соответствовать требованиям по блокировкам от РКН. Нужно также блочить те IP-адреса, которые никак не привязаны к доменным именам, именно такие ip и присутствуют в PAC-скрипте.

У вас не получится длительное время использовать модифицированный PAC-скрипт, нужно каждые N часов запрашивать новый скрипт для удовлетворения системы защиты от злоупотреблений прокси-серверами.

Убедитесь, что в настройках FireFox у вас отключен «DNS через HTTPS», т.к. один из серверов cloudflare, используемый для этого в FireFox, может быть блокирован вашим провайдером.

У вас проблемы с DNS, смените ваш DNS-сервер.

Адреса резолвятся через системный DNS, а не через DNS антизапрета. Если ваш провайдер блокирует сайты по IP, антизапрет будет работать только частично, т.к. не предназначен для таких провайдеров.

С помощью blockcheck v0.0.9.8 выяснил что проблемы с DNS на стороне провайдера и каноничные DNS-серверы прописывать бессмысленно.

[!] Результат:
[:warning:] Ваш провайдер блокирует сторонние IPv4 DNS-серверы.
Вам следует использовать шифрованный канал до DNS-серверов, например, через VPN, Tor, HTTPS/Socks прокси или DNSCrypt.
[:warning:] Ваш провайдер полностью блокирует доступ к HTTPS-сайтам из реестра.
[:warning:] У вашего провайдера “обычный” DPI. Вам поможет HTTPS/Socks прокси, VPN или Tor.

DNSCrypt помог. Осталось 3 вопроса. Почему проблемы с DNS не проявляются в Opera и прочих браузерах на вебките? Почему проблемы проявляются в Firefox только при включенном прокси Антизапрета? Что означает переменная dnsResolve(null), резолвинг через DNS Антизапрета?

Неплохо было бы добавить в инструкцию Антизапрета предупреждение что Firefox не работает с Антизапретом без DNSCrypt при блокировках сторонних DNS-серверов. Установить и настроить DNSCrypt конечно несколько сложнее чем вбить url скрипта автонастройки прокси в настройки браузера, что явно не добавит лисе популярности.

Большое всем спасибо что помогли разобраться.

ip = dnsResolve(hostname);

hostname – доменное имя.
dnsResolve – функция, принимающая доменное имя и возвращающая ip-адрес.

Я советовал вам заменить ip = dnsResolve(hostname) на ip = null.
То, как вы сделали, передав null вместо hostname, неожиданно тоже сработало, наверно, потому что функция может принимать ложные значения (false, '', 0, null и т.п.) и возвращает для них что-то типа null вместо ip-адреса, как я догадываюсь.

А попробуйте DNS over HTTPS: меню -> Настройки -> Основные -> Параметры сети -> Настроить… -> Отметить галочкой “Включить DNS через HTTPS”.

Для чистоты эксперимента проверил ip = null - тоже сработало.

ip-адреса открываемого ресурса? Тогда откуда Firefox берёт его когда там null?

Отключил DNSCrypt и включил DNS over HTTPS в Firefox.
Proxy.pac отключен: неблокированные ресурсы отлично загружаются как при использовании дефолтного DoH-резолвера Cloudflare, так и при использовании стороннего, оба резолвера не блокируются провайдером и открываются без каких-либо проблем.
Proxy.pac включен: с обоими DoH-резолверами неблокированные ресурсы лагают также как cо стандартными DNS.

В PAC-скрипте есть главная функция, что-то типа main в других языках программирования, но тут она называется FindProxyForURL(url, hostname). Эта функция вызывается при любом http-запросе браузера и в эту функцию передаются аргументы url и hostname для совершаемого запроса. hostname часто зовётся host, что я считаю неправильным (т.к. если адрес содержит порт, то это host, иначе hostname).

Так вот, внутри этой главной функции зовётся функция dnsResolve(hostname). В переменной hostname лежит доменное имя запроса, как я описал в предыдущем абзаце. Если hostname заменить на null, то dnsResolve не знает, ip адрес какого доменного имени вы от него требуете и, как я догадываюсь, возвращает опять null, но уже в качестве результата работы (а не аргумента в скобочках в dnsResolve(null)). При таком “холостом” вызове DNS-запроса не совершается совсем.

@ValdikSS, может, в этой версии FireFox dnsResolve использует системный DNS в обход DoH?

Я не вижу смысла разбираться в проблеме — очевидно, она вызвана проблемами с DNS.
Если хотите разобраться, начните с записи трафика на порт 53.

В PAC-скрипте используется не hostname, а host.
FindProxyForURL(url, host)
dnsResolve(host)
и тд.

Если при “холостом” вызове DNS-запроса не совершается совсем, то откуда браузер берёт ip? Это любая версия Firefox 69.* - 70.*. Чем проще всего записать трафик на 53 порт?

dnsResolve вызывается на каждый запрос, к любым сайтам. Эта функция не обязательно будет работать точно так же, как резолв домена в браузере.

Wireshark.

ip = dnsResolve(null) и ip = null аналогичны по моей догадке. ip не присваивается строка с адресом, вместо этого ему присваивается значение null (не строка). Если говорить о том, откуда тогда браузер берёт ip для сайта вообще, т.е. вне PAC-скрипта, то там уже отдельный скрипт и он, скорей всего, не на js.

Отправил всем в ЛС запись трафика на 53 порт. Всё записано при включенном proxy.pac, за исключением файла Firefox.pcapng. Особых отличий в запросах-ответах и таймингах между ними при лагах не вижу, но возможно что-то проглядел. Если они действительно не отличаются, тогда совсем непонятно почему движок Firefox ломается при включении proxy.pac.

Благодарю всех за помощь, это баги Firefox.

  1. Функция dnsResolve блокирует движок, если для некоторых из запрашиваемых страницой доменов не приходит никакого ответа от DNS. Это не позволяет движку загрузить контент с остальных доменов пока блокировка не снимется по таймауту, что сильно замедляет загрузку страницы.
  2. DNS-over-HTTPS не работает для функции dnsResolve. При включении DNS-over-HTTPS, все запросы функции dnsResolve идут к системному DNS на 53 порт.

Создал https://bugzilla.mozilla.org/show_bug.cgi?id=1592248. 127.0.0.1 у меня тоже проксируется, PAC-скрипт для него срабатывает, dns-пакеты отсылаются.