Как насчет формировать PAC-файл динамически под клиента?
Отдельный обучающий PAC-файл, в котором вместо перечня всех заблокированных только используемые/посещаемые клиентом ресурсы с разделением на DIRECT/PROXY.
Для всех пока не классифицированных ресурсов по умолчанию возвращает специальные обучающие PROXY.
Которые идентифицируют клиента и сохраняют для него списки для формирования его личного PAC-файла.
Подобный обучающий прокси может быть поднят самостоятельно.
Иной вариант это использование специального DNS-сервера и функции PAC-файла dnsResolve.
Скрипт добавляет нечто к исходному имени ресурса и пытается разрешить в IP-адрес.
Например для url c “ntc.party” добавляем несуществующий корневой домен “.antizapret” и полученное имя сервера “ntc.party.antizapret” пытаемся получить IP.
Если IP получили (или нет) можно сделать вывод надо или нет проксировать исходный URL.
А в зависимости от IP можно отправлять на разные прокси.
@ValdikSS Рассматривали сжатый DAWG (Directed Acyclic Word Graph)? Возможно подойдёт что-то такое
Да и base85 маловато для cp1252. Если оно все печатаемые символы хавает, можно намного больше взять
@ValdikSS
Попробовал на своем домене и vps поднять dnsmasq и поиграться с идеей разрешения адреса прокси.
Прикольно, оно работает.
Практически даже не требуется в dns-сервера (клиента) прописывать этот специальный dns, через глобальную dns прекрасно работает.
Так же можно не только домены но и отдельные заблокированные страницы и ip-адреса/подсети через dns узнавать онлайн - требуется проксирование или нет.
И получать свежие адреса прокси-серверов, без изменения PAC-скрипта.
Фактически некая маскировка под dns-трафик получается, двустороннее общение (из PAC-файла) со своими серверами, посредством функции dnsResolve.
Осталось продумать кодирование запросов/ответов и реализовать заполнение conf для dnsmasq.
В этот же список можно добавить:
(/caino/) {next}
(/cassino/) {next}
(/cazzino/) {next}
(/cazinno/) {next}
(/casiino/) {next}
(/casin0/) {next}
(/casi1no/) {next}
(/cas1no/) {next}
(/kacino/) {next}
(/kazzino/) {next}
(/cocaine/) {next}
(/businessinvest/) {next}
(/syka/) {next}
(/slot/) {next}
(/seeds/) {next}
(/fontan/) {next}
Спасибо, дополнил свой список
Вариант с PAC файлом в принципе не работает. По ссылке https://p.thenewone.lol:8443/proxy.pac открывается заглушка “This content has been blocked. Please contact team@pinata.cloud for more information - ERR_ID:00023”
Ссылка была заблочена но при этом сам pac-файл работал (у тех у кого это две отдельные сущности). Сейчас и он сам не работает. Нужно победить эту проблему, а она сложная.
PAC-файл уменьшен в размере путём проверки HTTP/HTTPS-работоспособности доменов, должен снова работать в Chrome-подобных браузерах при добавлении в настройки ОС.
А где взять рабочую ссылку на PAC-файл?
@ValdikSS @ilyaigpetrov Антицензорити придерживается лимитов на размер в 10 мегабайт и я используя его в ZeroOmega не замечаю каких-либо тяжёлых негативных эффектов. Можно спросить, почему лимит в 1 мегабайт так важен для Антизапрета и кого именно затронет практически НЕИЗБЕЖНЫЙ отход от лимита в 1 мегабайт? Допустим файл весит 3 мегабайта вместо 900 килобайт, какие негативные эффекты сразу ощутят конечные пользователи, в каких сценариях?
Все браузеры, основанные на Chromium (Chrome, Edge, Opera, Vivaldi, Brave), а также программы на CEF (Electron) не работают с PAC-файлами больше 1 МБ.
И ладно бы если просто не работали, но если файл по PAC-ссылке больше 1 МБ, они воспринимают это как временную проблему и не кешируют ответ, постоянно отправляя всё новые и новые запросы на скачивание файла, устраивая DDoS.
PAC-файл АнтиЗапрета >1МБ, вероятно, привёл к блокировке российских IP-адресов на IPFS-гейтвее pinata, а после переключения — к огромному количеству запросов на IPFS-гейтвей ipfs.io, что они были вынуждены сделать rate limit на 5 запросов в час с одного адреса — запросы PAC-файла просто съедали всю их пропускную способность.
I’m looking at our bandwidth utilization and
/ipfs/CID/proxy-ssl.jsand/ipfs/CID/proxy-nossl.jsare in TOP 3 of requested paths.
ok, seems that the fix was you ensuring size below 1MiB - it significantly cut down (1) bandwidth
it spiked again when I disabled rate-limits (2) and then got back down again (3) once I re-enabled them.
rate-limiting does not seem to have the same runaway effect as 1MiB thing – I think modern browsers/windows do support Retry-After, or have some sort of smart backoff when != 200 or 429 is returned.
PAC-файлы больше 1 МБ поддерживаются только в расширениях.
Чем меньше доменов в файле, тем быстрее он обрабатывается. Каждый запрос проиходит через PAC-функцию, поэтому чем быстрее она работает, тем меньше замедляются сетевые функции браузера.
В Реестре куча мусорных доменов/зеркал, которые технически работают, но никому не нужны.
Проблема устранена, по крайней мере на время. Если у кого есть более продуктивные идеи — пишите личным сообщением.
