libproxy вибирає маршрут; з'єднання встановлює ваш клієнт

Якщо libproxy повертає URI проксі, а наступний сокет підключається напряму, перевірте передавання. libproxy виявляє політику; він не перехоплює кожен сокет, який відкриває застосунок.

1. Запитайте ресурс. У документованому C API libproxy 0.5 створіть фабрику проксі та запитайте фактичний URL призначення.
2. Тлумачте впорядкованих кандидатів. Результати HTTP, SOCKS і прямі потребують різної обробки. Зберігайте їхній порядок переваги та передбачену політику відмов.
3. Налаштуйте споживача. Передайте вибраний тип проксі, кінцеву точку та порядок автентифікації транспорту, який їх підтримує. Необроблений сокет TCP не отримує узгодження CONNECT або SOCKS із повернутого URI.

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

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

У нативному коді дотримуйтеся життєвого циклу фабрики та пам'яті результатів встановленого API. Повторне використання фабрики може зберегти корисний стан виявлення, але все одно потребує запиту для кожного призначення. Записуйте вибір окремо від результату з'єднання: повернутий URI не доводить успішну автентифікацію, розв'язання чи подальший доступ.