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 სოკეტის კანდიდატი არ ადგენს, რომ ყველა კომპონენტი ერთსა და იმავე პროტოკოლს ან აუტენტიფიკაციას უჭერს მხარს.