libproxy выбирает маршрут; соединение устанавливает ваш клиент

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

1. Запросите ресурс. В документированном C API libproxy 0.5 создайте фабрику прокси и запросите фактический URL назначения.
2. Истолкуйте упорядоченных кандидатов. Результаты HTTP, SOCKS и прямые требуют разной обработки. Сохраняйте их порядок предпочтения и предполагаемую политику отказов.
3. Настройте потребителя. Передайте выбранный тип прокси, конечную точку и порядок аутентификации транспорту, который их поддерживает. Необработанный сокет TCP не получает согласование CONNECT или SOCKS из возвращённого URI.

Не сохраняйте один ответ как маршрут для всех назначений и не делайте прямое маршрутизирование постоянным только потому, что первый прокси однажды отказал.

Если HTTP-клиент уже интегрирует системный прокси или обнаружение PAC, выберите одного владельца выбора. Два независимых селектора плюс ещё одна обёртка могут дать маршрут, которого не предполагала ни одна из политик.

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