Запыты проксі 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-сокета не даказвае, што ўсе кампаненты падтрымліваюць той жа пратакол або аўтэнтыфікацыю.