Два параметра прокси могут создать цепочку, которую вы не планировали

Ваше приложение указывает на прокси B, но было запущено через обёртку, настроенную для прокси A. Какой выход видит сайт? Ответ зависит от того, какое соединение перехватывает обёртка.

В простой вложенной схеме приложение сначала пытается подключиться к B. Обёртка перехватывает это соединение и проводит его через A. Затем приложение говорит по протоколу прокси B поверх полученного потока, а B выполняет окончательное подключение к сайту.

application → wrapper proxy A → application proxy B → website

Сайт видит окончательное исходящее соединение B. B видит соединение, приходящее через A. Это отличается от случая, когда обёртка молча перезаписывает собственный параметр прокси приложения.

У простой схемы есть условия

Правила обхода, неподдерживаемые вызовы сокетов, существующие процессы и модель перехвата каждого продукта могут изменить путь. Некоторые обёртки могут исключать собственный прокси или выбранные назначения. Не считайте, что каждая пара инструментов сочетается одинаково.

Описание proxychains-ng объясняет его подход к перехвату и ограничения. Программа с собственной поддержкой прокси всё равно устанавливает сетевое соединение с этим прокси, что является одним из кандидатов на перехват.

Для намеренной цепочки неаутентифицированных публичных конечных точек список бесплатных прокси предлагает кандидатов, протоколы которых должны соответствовать каждому инструменту. При неожиданном выходе запишите три адреса отдельно: конечную точку, выбранную приложением, конечную точку, выбранную обёрткой, и результат, который видит сайт. Если смотреть только на настройки браузера, средний слой упускается.

Используйте один маршрут, пока устанавливаете нужное поведение, а второй добавляйте только если цепочка необходима. Дополнительные переходы могут добавить точки отказа и иные отношения доверия. Они не стирают автоматически идентифицирующие cookie и не заставляют каждое соединение приложения идти одним маршрутом.