Qt-Proxy-Abfragen enthalten die Art der Verbindung
Halten Sie Qts Proxy-Kandidaten mit der Ziel-URL und dem Vorgang verknüpft, statt ein Ergebnis als globale Adresse einzufrieren.
QNetworkProxyQuery query(QUrl(QStringLiteral("https://service.example.net/")));
const auto candidates = QNetworkProxyFactory::systemProxyForQuery(query);Diese Qt-Network-Abfrage prüft die Richtlinie für eine URL. Binden Sie die entsprechenden Qt-Network-Header ein. Sie öffnet keine Verbindung und ermittelt nicht die Route für jeden Socket im Prozess.
QNetworkProxyQuery enthält Zielinformationen und einen Abfragetyp. TCP-, UDP- und Servervorgänge können andere Fähigkeiten benötigen als ein HTTP-Caching-Proxy oder HTTP-Tunnel oder ein SOCKS-Proxy. Fragen Sie den fehlgeschlagenen Vorgang ab statt eine bequeme, unzusammenhängende öffentliche Seite.
Deuten Sie den Typ jedes Kandidaten. NoProxy wählt bewusst den direkten Zugriff; ein in diesem Ergebnis leer wirkender Host ist kein Erkennungsfehler. Bewahren Sie die Präferenzreihenfolge und alternative Kandidaten.
Wenn das Routing dynamisch bleiben soll, nutzen Sie die unterstützte Integration von Systemkonfiguration oder Proxy-Factory für den beteiligten Socket oder QNetworkAccessManager. Das Einfrieren des ersten Ergebnisses als festen Anwendungsendpunkt verwirft spätere Entscheidungen pro Ziel. Untersuchen Sie den tatsächlichen Manager oder die installierte Anwendungs-Factory: ein Diagnoseaufruf daneben belegt nicht, dass sie dieselbe Richtlinie verwendet.
Ein eingebetteter Browser kann einen anderen Netzwerk-Stack als Qt Network haben. Ein gültiger Qt-Socket-Kandidat belegt nicht, dass jede Komponente dasselbe Protokoll oder dieselbe Authentifizierung unterstützt.