Що вимірює leastconn у HAProxy всередині пулу SOCKS

Пул TCP у HAProxy обирає за активними з'єднаннями та вагами, а не за швидкістю завантаження цілі чи повним станом SOCKS.

listen socks_pool
    bind 127.0.0.1:1080
    mode tcp
    balance leastconn
    timeout connect 5s
    timeout client 1h
    timeout server 1h
    server proxy_a 192.0.2.10:1080 check
    server proxy_b 192.0.2.11:1080 check

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

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

Робочий тунель залишається на обраному бекенді. Цей пул TCP не передає окремі дейтаграми UDP ASSOCIATE.

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

Схожі статті