Заявките за прокси в 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 сокет не доказва, че всеки компонент поддържа същия протокол или удостоверяване.