Прокси-запросы Qt включают вид соединения
Держите прокси-кандидатов Qt связанными с целевым URL и операцией, а не замораживайте один результат как глобальный адрес.
QNetworkProxyQuery query(QUrl(QStringLiteral("https://service.example.net/")));
const auto candidates = QNetworkProxyFactory::systemProxyForQuery(query);Этот запрос Qt Network проверяет политику для одного URL. Подключите соответствующие заголовки Qt Network. Он не открывает соединение и не определяет маршрут для каждого сокета в процессе.
QNetworkProxyQuery содержит информацию о назначении и тип запроса. Операциям TCP, UDP и сервера могут потребоваться иные возможности, чем кеширующему прокси HTTP или туннелю HTTP, либо прокси SOCKS. Запрашивайте неудачную операцию, а не удобную несвязанную публичную страницу.
Интерпретируйте тип каждого кандидата. NoProxy намеренно выбирает прямой доступ; хост, выглядящий пустым в этом результате, не является ошибкой обнаружения. Сохраняйте порядок предпочтения и альтернативных кандидатов.
Когда маршрутизация должна оставаться динамической, используйте поддерживаемую интеграцию системной конфигурации или фабрики прокси для участвующего сокета или QNetworkAccessManager. Замораживание первого результата как фиксированной конечной точки приложения отбрасывает последующие решения для каждого назначения. Проверьте фактический менеджер или установленную фабрику приложений: диагностический вызов рядом с ним не доказывает, что она использует ту же политику.
Встроенный браузер может иметь другой сетевой стек, чем Qt Network. Допустимый кандидат сокета Qt не доказывает, что каждый компонент поддерживает тот же протокол или аутентификацию.