მომწოდებელთან სწორი პაროლი არ ქმნის შესაბამის რწმუნებას რეალურად არჩეული პროქსისთვის. დაიწყეთ იმ საბოლოო წერტილის სქემით, ჰოსტით და პორტით; ჰოსტის ველი ჩვეულებრივ მხოლოდ ჰოსტის სახელს ან IP-ს იღებს, არა სრულ URL-ს.

  1. წაიკითხეთ მთელი ავთენტიფიკაციის გაცვლა. ერთი 407, რომელსაც მოჰყვება მიღებული ხელახალი ცდა შეიძლება ნორმალური იყოს. სანამ შესვლას უარყოფილად ჩათვლით, დაადასტურეთ, რომ საბოლოო შედეგი კვლავ 407-ია.
  2. შეადარეთ მარშრუტი და რწმუნებების არე. შეუსაბამეთ ფაქტობრივი ჰოსტი/პორტი და სხვა ველები, რომლებიც განსაზღვრულია განლაგებული HttpClient 5 AuthScope-ით. არასწორმა პორტმა შეიძლება BasicCredentialsProvider შესაბამისი ჩანაწერის გარეშე დატოვოს.
  3. შეამოწმეთ მეთოდი და იდენტობა. შემოგვთავაზა პროქსიმ მხარდაჭერილი მეთოდი? გამოიყენა ხელახალმა ცდამ მოსალოდნელი კავშირი? მოითხოვს ოპერატორი დომენით კვალიფიცირებულ ანგარიშს თუ სხვა დოკუმენტირებულ ფორმატს?

გამოიყენეთ დაყენებული ძირითადი ვერსიის API. HttpClient 4-ის ავთენტიფიკაციის ქეშის რეცეპტი უცვლელად არ გადადის მე-5 ვერსიაში. გამოიყენეთ ოპერატორის ანგარიშის მოთხოვნები, ნაცვლად თვითნებური მომხმარებლის სახელის ვარიანტების ცდისა.

წინასწარი ავთენტიფიკაცია კიდევ ერთი განზრახ არჩევანია. თავსებადი სქემისთვის მან შეიძლება ერთი ციკლი მოხსნას, მაგრამ ცვლის, როდის გადის რწმუნებები და საჭიროებს მხარდაჭერილ არეს. ის არ შეიძლება იყოს პირველი შესწორება შეუსაბამო საბოლოო წერტილის ან მხარდაუჭერელი მეთოდისთვის.

შეინახეთ გამოწვევის ქვეშ მყოფი პროქსის იდენტობა, მეთოდი, არეს შესაბამისობა და საბოლოო სტატუსი რედაქტირებულ დიაგნოსტიკაში. პაროლი და რწმუნებების მატარებელი ნედლი კვალი ამ შედარებისთვის არ არის საჭირო.

დაკავშირებული სტატიები