Qt-proxyforespørgsler omfatter forbindelsestypen
Hold Qts proxykandidater knyttet til mål-URL'en og handlingen i stedet for at fryse ét resultat som en global adresse.
QNetworkProxyQuery query(QUrl(QStringLiteral("https://service.example.net/")));
const auto candidates = QNetworkProxyFactory::systemProxyForQuery(query);Denne Qt Network-forespørgsel undersøger politik for én URL. Medtag de tilsvarende Qt Network-headere. Den åbner ikke en forbindelse og identificerer ikke ruten for hver socket i processen.
QNetworkProxyQuery indeholder destinationsoplysninger og en forespørgselstype. TCP-, UDP- og serverhandlinger kan kræve andre egenskaber end en HTTP-cacheproxy eller HTTP-tunnel eller en SOCKS-proxy. Forespørg den mislykkede handling i stedet for en bekvem, urelateret offentlig side.
Fortolk hver kandidats type. NoProxy vælger bevidst direkte adgang; en vært, der ser tom ud i det resultat, er ikke en opdagelsesfejl. Bevar præferenceordenen og alternative kandidater.
Når routing skal forblive dynamisk, brug den understøttede integration af systemkonfiguration eller proxyfabrik for den deltagende socket eller QNetworkAccessManager. At fryse det første resultat som et fast applikationsendepunkt kasserer senere beslutninger pr. destination. Undersøg den faktiske manager eller den installerede applikationsfabrik: et diagnostisk kald ved siden af beviser ikke, at den bruger samme politik.
En indlejret browser kan have en anden netværksstak end Qt Network. En gyldig Qt-socket-kandidat fastslår ikke, at hver komponent understøtter samme protokol eller godkendelse.