Proxy.pac ломает Firefox 69.* - 70.0

При использовании https://antizapret.prostovpn.org/proxy.pac в Firefox 69.* - 70.0 на Windows 7 64-bit все сайты загружаются около минуты, в т.ч. любые неблокированные, например Хабр. Включение или отключение DNS-over-HTTPS никакого заметного эффекта не оказывает. Проверено на нескольких чистых инсталляциях без дополнений и пользовательских настроек. При отключении proxy.pac неблокированные сайты загружаются практически мгновенно. В браузерах на базе WebKit использование https://antizapret.prostovpn.org/proxy.pac на этом же компьютере не вызывает никаких проблем с загрузкой любых сайтов.

Windows 7 32 bit, Firefox 70.0 — не проявляется. Запуск браузера происходит быстро, вне зависимости от наличия или отсутствия PAC-файла, заблокированные и незаблокированные сайты открываются без задержки.
Тестировал на новом профиле и профиле, который использовал ранее.

Попробуйте открыть консоль браузера (CTRL+SHIFT+J) и посмотреть, происходит ли что-либо.

При включенном proxy.pac в чистом Firefox 69.0.3 64-bit с новым профилем:

PAC file installed from https://cloudflare-ipfs.com/ipns/pacipfs2.antizapret.prostovpn.org/proxy-ssl.js
Key event недоступен при использовании некоторых раскладок клавиатуры: ключ=«i» модификаторы=«accel,alt,shift» id=«key_browserToolbox» browser.xhtml
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] 2 network-response-listener.js:86
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] network-response-listener.js:86

При отключенном proxy.pac ошибки NS_ERROR_FAILURE отсутствуют.

При включенном proxy.pac в Firefox 70.0 64-bit Safemode:

[Exception… “Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]” nsresult: “0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)” location: “JS frame :: resource://gre/modules/L10nRegistry.jsm :: this.L10nRegistry.loadSync :: line 759” data: no] 2 L10nRegistry.jsm:759:19
uncaught exception: 2147746065 SessionStore.jsm:5512:20
Unknown category for SetEventRecordingEnabled: fxmonitor
PAC file installed from https://cloudflare-ipfs.com/ipns/pacipfs2.antizapret.prostovpn.org/proxy-ssl.js
NS_ERROR_XPC_GS_RETURNED_FAILURE: ServiceManager::GetService returned failure code: UrlClassifierListManager.jsm:73
NS_ERROR_XPC_GS_RETURNED_FAILURE: ServiceManager::GetService returned failure code: SafeBrowsing.jsm:303
[Exception… “Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]” nsresult: “0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)” location: “JS frame :: resource://gre/modules/L10nRegistry.jsm :: this.L10nRegistry.loadSync :: line 759” data: no] 2 L10nRegistry.jsm:759:19
Key event недоступен при использовании некоторых раскладок клавиатуры: ключ=«i» модификаторы=«accel,alt,shift» id=«key_browserToolbox»

Может, у вас с DNS что-то не так? Попробуйте сменить сервер.

Попробовал, не помогло. Если бы проблема была с DNS, то на вебките она тоже должна была проявиться. При включенном proxy.pac в статусной строке Firefox во время загрузки незаблокированного сайта висит “Передача данных с домен с которого идёт загрузка контента”. То есть контент грузится и домены резолвятся, но внутри движка браузера что-то очень сильно замедляет процесс загрузки при включенном proxy.pac. Не удивлюсь если Firefox вовсе игнорирует правила и все сайты пускает через серверы Антизапрета. Есть подозрения что это баг 64-битной версии Firefox для Windows.

Протестировал на 64-битной Windows 7 с 64-битным Firefox 70.0 — всё в порядке. Видимо, это особенности вашей системы или DNS-сервера.

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

Хотелось бы понять куда копать. Проверил на другой машине в той же сети (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 порт?