Les requêtes de proxy Qt incluent le type de connexion
Gardez les candidats de proxy de Qt associés à l'URL et à l'opération cibles au lieu de figer un résultat comme adresse globale.
QNetworkProxyQuery query(QUrl(QStringLiteral("https://service.example.net/")));
const auto candidates = QNetworkProxyFactory::systemProxyForQuery(query);Cette requête Qt Network examine la politique d'une URL. Incluez les en-têtes Qt Network correspondants. Elle n'ouvre pas de connexion et n'identifie pas la route de chaque socket du processus.
QNetworkProxyQuery contient des informations de destination et un type de requête. Les opérations TCP, UDP et serveur peuvent nécessiter des capacités différentes de celles d'un proxy de cache HTTP ou d'un tunnel HTTP, ou d'un proxy SOCKS. Interrogez l'opération qui a échoué plutôt qu'une page publique pratique et sans rapport.
Interprétez le type de chaque candidat. NoProxy choisit délibérément l'accès direct ; un hôte qui semble vide dans ce résultat n'est pas un échec de découverte. Conservez l'ordre de préférence et les candidats alternatifs.
Lorsque le routage doit rester dynamique, utilisez l'intégration prise en charge de la configuration système ou de la fabrique de proxy pour le socket ou le QNetworkAccessManager participant. Figer le premier résultat comme point de terminaison fixe de l'application écarte les décisions ultérieures par destination. Inspectez le gestionnaire réel ou la fabrique d'applications installée : un appel de diagnostic à côté ne prouve pas qu'elle utilise la même politique.
Un navigateur embarqué peut avoir une pile réseau différente de celle de Qt Network. Un candidat de socket Qt valide n'établit pas que chaque composant prend en charge le même protocole ou la même authentification.