განათავსეთ Netty-ის SOCKS მოლაპარაკება თქვენი აპლიკაციის პროტოკოლამდე

არსებული Netty bootstrap/pipeline-ისთვის, სადაც SOCKS სერვერმა უნდა გადაწყვიტოს დანიშნულება:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

პროქსის ბოლო წერტილი ლოკალური პორტი 1080-ია; გადაუწყვეტელი კავშირის სამიზნეა example.com:443. ნუ გამოიყენებთ პროქსის მისამართს ორივე როლისთვის და ნუ გადაწყვეტთ სახელს, სანამ დამმუშავებელი მიიღებს მას. დაშვებულ საჯარო პროქსის მარშრუტზე საჯარო სამიზნეებისთვის SOCKS5 პროქსების სია გთავაზობთ კანდიდატებს დამმუშავებლის პროქსის ბოლო წერტილისთვის.

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

HTTPS-ისთვის შემდეგი TLS ფენა იყენებს დანიშნულების ჰოსტის სახელს, საჭირო შემოწმებასა და ნდობას—და არა SOCKS ბოლო წერტილის იდენტობას. მხოლოდ ამის შემდეგ იწყება HTTP/აპლიკაციის გაცვლა.

ფრაგმენტი არ გთავაზობთ მოვლენების ციკლებს, არხის ტიპებს, TLS/HTTP დამმუშავებლებს ან შეცდომების ჩვეულებრივ დამუშავებას. აირჩიეთ ავთენტიფიკაციის მოთხოვნების შესაბამისი SOCKS კონსტრუქტორი; HTTP Basic დამმუშავებელი სხვა პროტოკოლია.

გამოიყენეთ no-op resolver მხოლოდ იქ, სადაც ამ ქვედა დამმუშავებელს ეკუთვნის ჰოსტის სახელის გადაწყვეტა. სხვა კავშირებს შეიძლება დასჭირდეს ლოკალური ძებნა. ჩავარდნის დიაგნოსტიკისას ცალ-ცალკე შეინახეთ resolver-ის გამომავალი, პროქსის future, TLS და აპლიკაციის შედეგი.