Проксі-запити 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 не доводить, що кожен компонент підтримує той самий протокол чи автентифікацію.