• Тип настройки: PAC-файл / браузерное расширение / VPN
• Тип проблемы: не работает НЕзаблокированный сайт
• Что с сайтом: вместо сайта открывается страница-заглушка
• Используемый браузер: FF

Описание проблемы

Сайты, самостоятельно блокирующие доступ пользователям из России, вручную в список не добавляются (не считая единичных исключений).

В качестве единичных исключений, могу я попросить добавить:

• https://download.qt.io/
• https://wise.com/

Есть ли тема, где можно оставлять подобные запросы?
Спасибо.

Добавление новых сайтов не осуществляется.

OK, может быть тогда подскажете как лучше настроить FF/систему чтобы доступ к этим сайтам осуществлялся прозрачно?
У меня есть частная прокся, но включать/выключать её в настройках FF каждый раз неудобно.

Можно прописать свой прокси в нашем расширении: см. https://github.com/anticensority/runet-censorship-bypass/wiki/Свои-прокси-в-расширении.
Но там есть ограничения на тип и пароль.

Спасибо, не могли бы вы описать как это будет работать? Или может это уже где-то написано.
Мне нужно чтобы моя прокся использовалась только для определенных сайтов.

Ссылку уже дал.
Вот вам снимки в помощь:

ac-own-proxies404×625 72.1 KB

Спасибо. Правильно ли я понимаю что при этих настройках PAC-script не будет использоваться вообще?
Тогда это не совсем то что мне нужно.
Я хотел использовать PAC-скрипт (предпочтительно с публичными проксями) + свою проксю для нескольких заданных сайтов

1. PAC-скрипт: АнтиЗапрет
2. На вкладке “Свои прокси / Own proxies”:
   [V] Использовать прокси PAC-скрипта
   [V] Использовать СВОИ прокси
   [V] СВОИ прокси только для СВОИХ сайтов
3. Нужно добавить свои адреса для проксирования на вкладке “Исключения / Exceptions”, режим редактора открывается через ⇄.

Большое спасибо, попробую. Похоже то что нужно

Сразу же в догонку ещё вопрос:
будет ли приложение работать на FF Mobile и если нет, какие перспективы сделать его таковым?

Под Android не хватает вот этого API: см. Проголосуйте за исправление багов в браузерах · Issue #76 · anticensority/runet-censorship-bypass · GitHub.

Можно ли как-нибудь обойтись без этого API?

Аналогичный менеджер прокси работает на FF Mobile:

В этой версии FoxyProxy используется API proxy.settings: см. https://github.com/foxyproxy/browser-extension/blob/c9b03dc3b86f3f2f9bb31663e7514ca6023454f4/src/content/proxy.js#L57. В том же файле можно найти множество таких обращений к нужному API.

Так вы проверяли его на Андроиде? Работает?

Не проверял, спрашивал:

Может быть было бы полезно если бы вы нашли с автором общее решение, если это не так.

К сожалению, использовать свою HTTP(S?) проксю с паролем пока не удается.

Возможные причины:

• используется версия для медленных машин (?, см. скриншот) в которой функция паролей не заявлена (хотя встроенная справка по формату записей прокси предлагает ввод этих данных).
  Действительно ли это так и где тогда взять нормальную версию для FF?
• в пароле используются пробелы, возможно это вызывает проблемы. Поменять пароль я не могу.
• неверный тип прокси.
  Я пробовал PROXY, HTTPS типы. При этом ошибки разные: Unable to connect, Secure Connection Failed.
  НО!
  В аналогичном расширении FoxyProxy, моя прокся заработала только с типом HTTP (без S) - но этот тип данное расширение не даёт ввести в редакторе, возможен лишь PROXY. Не может быть в этом проблема?

И сразу следующий вопрос - как быть с редактором исключений в FF?
На скриншоте видно что “Редактор исключений доступен только для вкладок”, при нажатии на ссылку “вкладок” ничего не происходит.

1. Под FireFox есть только полная версия, версия МИНИ – только для Хрома и производных.

2. Типы PROXY и HTTP – это одно и то же.

3. Проверить свой прокси можно через curl -x "protocol://user:password@your-proxy-ip-address" https://www.kasparov.ru

4. при нажатии на ссылку “вкладок” ничего не происходит.

   Просто откойте новую вкладку и кликните по иконке синей ленты.

   на вкладке “Исключения / Exceptions”, режим редактора открывается через ⇄.

Есть подозрение что дело всё же в пробелах:

• Если использую схему https, выдает curl: (56) CONNECT tunnel failed, response 400
• При http схеме:
  • Если в пароле пробелы - ошибка curl: (5) Unsupported proxy syntax in 'http://user:passw with spaces@...'
  • Убираю пробелы (и делаю пароль неправильным) - бесконечно висит

Есть идеи как победить?

На месте пробела впишите %20.

См. Special Characters in Usernames and Passwords.

https://www.urlencoder.org, если не боитесь спалить пароль.

Теперь:

• схема http:
  curl: (56) CONNECT tunnel failed, response 307
• https:
  curl: (35) OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number

Но прокся рабочая, я ей же пользуюсь через встроенные FF настройки.

Чтобы вывести больше подробностей об ошибке, добавьте флаг -v.
Пример: curl -x "protocol://user:password@your-proxy-ip-address" -v https://www.kasparov.ru

• http:

  ...
  > CONNECT www.kasparov.ru:443 HTTP/1.1
  > Host: www.kasparov.ru:443
  > Proxy-Authorization: Basic ****
  > User-Agent: curl/7.88.1
  > Proxy-Connection: Keep-Alive
  > 
  < HTTP/1.1 307 Temporary Redirect 
  < Via: 1.0 middlebox
  < Location: http://forbidden.yota.ru/
  < Connection: close
  < 
  * CONNECT tunnel failed, response 307
  * Closing connection 0
  curl: (56) CONNECT tunnel failed, response 307
  

• https:

  ...
  * ALPN: offers http/1.1
  * TLSv1.3 (OUT), TLS handshake, Client hello (1):
  *  CAfile: /etc/ssl/certs/ca-certificates.crt
  *  CApath: /etc/ssl/certs
  * OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number
  * Closing connection 0
  curl: (35) OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number

Закодировать свой пароль можно так:

1. Нажать F12 – откроется инструментарий разработчика (devtools).
2. Ввести encodeURIComponent('тут-пароль'). Скопировать результат и вставить в команду проверки прокси: curl -x "http://user:password@your-proxy-ip-address" -v https://www.kasparov.ru

ac-encode-very-hard-password969×584 154 KB

Подождите, разве дело в пароле?
Я вроде заменил на %20, там больше ничего нет такого

Кстати говоря, если я использую публичную проксю, то результат тот же:

$ curl -x "203.23.103.182:80" https://www.kasparov.ru -v
*   Trying 203.23.103.182:80...
* Connected to 203.23.103.182 (203.23.103.182) port 80 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to www.kasparov.ru:443
> CONNECT www.kasparov.ru:443 HTTP/1.1
> Host: www.kasparov.ru:443
> User-Agent: curl/7.88.1
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 307 Temporary Redirect 
< Via: 1.0 middlebox
< Location: http://forbidden.yota.ru/
< Connection: close
< 
* CONNECT tunnel failed, response 307
* Closing connection 0
curl: (56) CONNECT tunnel failed, response 307

Протокол не указан. Попробуйте "http://203.23.103.182:80".

Видимо протокол опционален, потому как если с ним что-то не так - ошибка иная.

В любом случае, ничего не поменялось:

$ curl -x "http://203.23.103.182:80" https://www.kasparov.ru -v
*   Trying 203.23.103.182:80...
* Connected to 203.23.103.182 (203.23.103.182) port 80 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to www.kasparov.ru:443
> CONNECT www.kasparov.ru:443 HTTP/1.1
> Host: www.kasparov.ru:443
> User-Agent: curl/7.88.1
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 307 Temporary Redirect 
< Via: 1.0 middlebox
< Location: http://forbidden.yota.ru/
< Connection: close
< 
* CONNECT tunnel failed, response 307
* Closing connection 0
curl: (56) CONNECT tunnel failed, response 307

Я не силён в анализе сетевых логов, но складывается ощущение, что устройство на стороне провайдера замечает попытку подключения к прокси-серверу по нешифрованному протоколку HTTP. Поскольку протокол нешифрованный, устройство на стороне провайдера вмешивается в сессию и перенаправляет на заглушку. Если это так, то следует найти шифрованный прокси типа HTTPS.

Но то, что в другом расширении этот же нешифрованный протокол работает, ставит мою гипотезу под сомнение.

Именно

Похоже дело вообще не в пароле и не в типе прокси:
если я использую http://203.23.103.182:80 в стандартных настройках для типа HTTP - всё работает, даже HTTPS сайты.
Но в вашем приложении эта же прокся не работает.

Требуется доп. тестирование

Я потестировал ещё и вот что удалось выяснить.

Да, действительно провайдер вклинивался в сессию - но я потом вспомнил, это было и раньше.
Дело в том, что наш тест некорректен - при тестировании на сайте, заблокированном РКН, будем всегда получать отлуп в независимости от типа прокси: HTTP/HTTPS (SOCKS не пробовал).
Это было и с моей проксей.

Корректный тест - на сайте, заблокированном извне для России. Например, wise.com.
Для него любая HTTPS прокся из публичного списка начинает работать, НО только будучи введенной в стандартные настройки FF:
https://hidemyna.me/ru/proxy-list/?type=s#list

Из вашего приложения не работает, как я ни пытался.

Вы можете воспроизвести проблему у себя?

Странность заключается в том, что даже в том проложении (FoxyProxy), где моя HTTP(S) прокся работает - она работает только как тип HTTP (без S), и при этом открывает HTTPS сайты:

Может быть, тип HTTP всё же отличается от PROXY в FF?

HTTP-прокси это классический нешифрованный протокол прокси, он способен открывать HTTPS-сайты методом CONNECT. В браузерном PAC-файле такие прокси обозначаются префиксом PROXY.

HTTPS-прокси это тот же самый HTTP-прокси с дополнительным слоем TLS для шифрования. В браузере они называются HTTPS.

Ваш прокси, вероятно, без TLS. Его нужно использовать с префиксом PROXY.

Спасибо за информацию.
Как я уже сказал, проблема похоже не в моём прокси - я пробовал разные прокси из публичного списка, с разными префиксами.
Ни одна комбинация не работает.

Прошу подтвердить проблему.
FF 115.0.2

Прокси с https://hidemyna.me/ru/proxy-list/?type=s#list по моему предыдущему опыту долго не живут. Попробуйте найти прокси, который работает у вас в другом расширении, но не работает в нашем. Пришлите его координаты мне для тестирования, публично или приватно. Можно через личные сообщения на ntc.party.

Я понимаю, но проблема в том что все эти прокси работают в другом расширении, но не в вашем.
Так что думаю не имеет особого значения что это за прокся, попробуйте для начала завести хоть одну из этого источника. Они как правило рабочие если брать с верхушки.
Спасибо.

Все прокси с https://hidemyna.me/ru/proxy-list/?type=s#list с типом https, что я пробовал, по факту по https не работают, а работают по http.

Пример:

$ curl -v -x https://89.43.31.134:3128 https://kasparov.ru
*   Trying 89.43.31.134:3128...
* Connected to (nil) (89.43.31.134) port 3128 (#0)
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* (5454) (IN), , Unknown (72):
* error:0A00010B:SSL routines::wrong version number
* Closing connection 0
curl: (35) error:0A00010B:SSL routines::wrong version number

Провреил в curl https прокси-сервер из PAC-скрипта АнтиЗапрет – работает.
В других расширениях вы, вероятно, используете прокси с типом http, а не httpS.

Вы пробовали в своем расширении?
Просьба попробовать, они у меня не работали ни с каким типом именно в вашем расширении.

HTTPS-прокси не проходят проверку даже в curl.
В работу же HTTP-прокси вклинивается провайдер, так что их даже и не стоит проверять.
Но я проверил, результат – на снимке ниже.

Я писал об этом:

Вы можете проверить с сайтом wise.com?

В исключения сайт добавил.

Согласен, что-то не так.
Я вам ответил в ЛС, давайте попробуем с моей проксей.

Всё заработало, спасибо.