При использовании 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.
Методика тестирования:
- Отключаем proxy.pac в настройках Firefox
- Открываем приватное окно
- Включаем сетевой монитор Firefox из инструментов разработчика
- Загружаем неблокированный url и дожидаемся полной загрузки
- Записываем время DOMContentLoaded и load
- Закрываем приватное окно
- Включаем proxy.pac в настройках прокси
- Открываем приватное окно и повторяем шаги с 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 мин
Попробуйте так:
- Скачать свежий PAC-скрипт (проделать обязательно).
- Модифицировать в нём строчку, которая может вызывать замедление. Для начала можно заменить
dnsResolve(...)наnullи проверить, в DNS ли проблема. - Настроить 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-серверы прописывать бессмысленно.
[!] Результат:
[] Ваш провайдер блокирует сторонние IPv4 DNS-серверы.
Вам следует использовать шифрованный канал до DNS-серверов, например, через VPN, Tor, HTTPS/Socks прокси или DNSCrypt.
[
[
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 вызывается на каждый запрос, к любым сайтам. Эта функция не обязательно будет работать точно так же, как резолв домена в браузере.
ip = dnsResolve(null) и ip = null аналогичны по моей догадке. ip не присваивается строка с адресом, вместо этого ему присваивается значение null (не строка). Если говорить о том, откуда тогда браузер берёт ip для сайта вообще, т.е. вне PAC-скрипта, то там уже отдельный скрипт и он, скорей всего, не на js.
Отправил всем в ЛС запись трафика на 53 порт. Всё записано при включенном proxy.pac, за исключением файла Firefox.pcapng. Особых отличий в запросах-ответах и таймингах между ними при лагах не вижу, но возможно что-то проглядел. Если они действительно не отличаются, тогда совсем непонятно почему движок Firefox ломается при включении proxy.pac.
Благодарю всех за помощь, это баги Firefox.
- Функция dnsResolve блокирует движок, если для некоторых из запрашиваемых страницой доменов не приходит никакого ответа от DNS. Это не позволяет движку загрузить контент с остальных доменов пока блокировка не снимется по таймауту, что сильно замедляет загрузку страницы.
- 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-пакеты отсылаются.
Странно что 127.0.0.1 проксируется, в Firefox на Windows он в исключениях. Второй баг тоже надо зарепортить, у них там какой-то говнокод, если сравнивать с вебкитом. Видимо в вебките это как-то асинхронно исполняется.
Попробуйте отправить им второй баг самостоятельно, я мало заинтересован в том, чтобы чинить FireFox для работы с блокировками на уровне DNS, мне нужно, чтобы наши PAC-скрипты работали у пользователей безопасно (т.е. через DoH) и независимо от системных DNS, когда нужно.
WebKit-браузеры на windows – это, наверно, уже редкость, я ни одного не знаю. Хромиум перешёл на собственный движок Blink.
Спасибо, дописал к репорту. Кстати, какой практический смысл в резолвинге через dnsResolve(), а не напрямую через движок?
Внутри PAC-скрипта вам не известен IP-адрес. Единственный способ там его получить – это dnsResolve. Почему dnsResolve работает не так, как адресная строка браузера, я не знаю. По идее dnsResolve отрабатывает до отправки DNS-запроса адресной строки (к примеру, этот dns-запрос вообще может быть передан прокси-серверу, установленному через PAC-скрипт).