@Q_Q Я использую образ Docker с Podman (альтернатива Docker), и, похоже, есть какая-то ошибка в том, что Podman Desktop на Windows принимает соединения только с "localhost" (или с "::1" для IPv6), но не с "127.0.0.1" при использовании аргумента "net=host".
Но теперь я перенастроил контейнер и использую режим "net=bridge".
Таким образом, образ контейнера, обеспечивающий прокси, по-прежнему работает, и к нему можно получить доступ через "127.0.0.1", а значит, он также работает в BAS.
Отключение определения IP в действии "Прокси"
-
Здравствуйте!
Проблема: действие «Прокси» тратит около 40 секунд на попытку подключения к невалидному прокси, что является критичной задержкой.
Вопрос: Можно ли отключить определение публичного IP-адреса в действии «Прокси» и вместо этого задавать IP WebRTC, часовой пояс и другие параметры через действие «Установить месторасположение браузера по IP»? Корректно ли работает это действие и обеспечивает ли оно аналогичный результат, как соответствующая функция в кубике «Прокси»?
-
@Irbe Без определения валидности прокси у тебя уйдёт ещё больше времени на определение валидности прокси. Другими словами: если прокси нерабочий, то придётся делать доп. кубики на определение его неработоспособности.
Делай проверку через другие API определения работоспособности, подбирай более быстрые и стабильные, например:https://ipv4.seeip.org https://icanhazip.com https://api.ip.sb/ip https://api.myip.la https://api.ipify.orgИ ещё совет, проверяй свои прокси на работоспособность перед запуском программы.
-
@gurkin4 Я просто хочу самостоятельно определять валидность и публичный IP-адрес прокси через HTTP-клиент.
Дальше установить прокси без определения IP и задать IP (который мы узнали самостоятельно с помощью HTTP-клиента) через действие «Установить месторасположение браузера по IP». Вопрос в том, корректно ли работает это действие и обеспечивает ли оно аналогичный результат, как соответствующая функция в кубике «Прокси»?
