Два налаштування проксі можуть створити ланцюг, якого ви не планували

Ваш застосунок указує на проксі B, але його запущено через обгортку, налаштовану для проксі A. Який вихід бачить сайт? Відповідь залежить від того, яке з'єднання перехоплює обгортка.

У простій вкладеній схемі застосунок спершу намагається підключитися до B. Обгортка перехоплює це з'єднання й проводить його через A. Далі застосунок говорить протоколом проксі B поверх отриманого потоку, а B виконує остаточне підключення до сайту.

application → wrapper proxy A → application proxy B → website

Сайт бачить остаточне вихідне з'єднання B. B бачить з'єднання, що надходить через A. Це відрізняється від випадку, коли обгортка мовчки перезаписує власне налаштування проксі застосунку.

Проста схема має умови

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

Опис proxychains-ng пояснює його підхід до перехоплення та обмеження. Програма з нативною підтримкою проксі все одно встановлює мережеве з'єднання з цим проксі, що є одним із кандидатів на перехоплення.

Для навмисного ланцюга неавтентифікованих публічних кінцевих точок список безкоштовних проксі пропонує кандидатів, протоколи яких мають відповідати кожному інструменту. У разі неочікуваного виходу запишіть три адреси окремо: кінцеву точку, яку вибрав застосунок, кінцеву точку, яку вибрала обгортка, і результат, який бачить сайт. Якщо дивитися лише на налаштування браузера, середній шар пропускається.

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