TCP সংযোগ সফল হওয়ার পর প্রক্সি CONNECT টাইমআউট
সম্পূর্ণ TCP সংযোগ টানেল সেটআপও সম্পন্ন করেছে ভেবে নেওয়ার বদলে CONNECT চলাকালীন সক্রিয় টাইমআউটটি খুঁজে বের করুন।
ক্লায়েন্ট প্রক্সির সাথে সংযুক্ত হওয়ার সাথে সাথেই TCP সংযোগ টাইমআউট তার কাজ শেষ করে ফেলে। পরবর্তী অপেক্ষা—একটি সম্পূর্ণ CONNECT উত্তর গ্রহণ—সম্ভবত ভিন্ন কোনো টাইমার দ্বারা নিয়ন্ত্রিত হয়।
প্রক্সি হয়তো তখনও আপস্ট্রিমে সংযোগ স্থাপন করছে, প্রমাণীকরণ বার্তা বিনিময় করছে বা অন্য কোনো সেবার জন্য অপেক্ষা করছে। ওয়েবসাইটের স্বাভাবিক উত্তর তখনও শুরু হয়নি।
| সর্বশেষ সম্পন্ন ধাপ | এখনও কীসের অপেক্ষা? |
|---|---|
| প্রক্সিতে TCP সংযুক্ত | প্রক্সি হ্যান্ডশেক, CONNECT গ্রহণসহ |
| CONNECT গ্রহণ করা হয়েছে | গন্তব্যের TLS, যখন লক্ষ্যটি এটি ব্যবহার করে |
| গন্তব্যে অনুরোধ পাঠানো হয়েছে | গন্তব্যের উত্তর |
কানেক্টর যখন ওই হ্যান্ডশেক পড়ছে ও লিখছে তখন কোন টাইমার সক্রিয় তা খুঁজে বের করুন। “response timeout” নামের একটি বৈশিষ্ট্য রুট প্রতিষ্ঠার পরেই কার্যকর হতে পারে। HttpClient 5-এ ConnectionConfig এবং তার সকেট টাইমআউট, TLS হ্যান্ডশেক কনফিগারেশন এবং অনুরোধ-স্তরের প্রতিক্রিয়া টাইমআউট আলাদা করুন। প্রাসঙ্গিক সংযোগ কনফিগারেশনটি বাস্তব ক্লায়েন্ট যে ম্যানেজার ব্যবহার করে তার মাধ্যমে প্রয়োগ করুন। পুরোনো Apache HttpClient প্রজন্মগুলো ভিন্ন API ব্যবহার করে, তাই পুরোনো স্নিপেট এই দায়িত্বগুলোর বিশ্বাসযোগ্য মানচিত্র নয়।
চূড়ান্ত CONNECT প্রত্যাখ্যানকে প্রক্সির উত্তর হিসেবেই রাখুন। সফল উত্তর পাওয়ার পর TLS আটকে যাওয়া আরেকটি ব্যর্থতার ধাপ। “TCP সংযুক্ত; সেটআপ সময়সীমার আগে সম্পূর্ণ CONNECT উত্তর নেই” বাক্যটি সাধারণ প্রক্সি টাইমআউটের চেয়ে সমস্যাটিকে আরও নিখুঁতভাবে বর্ণনা করে।
একটি সামগ্রিক সময়সীমা এই ধাপভিত্তিক সীমাগুলোর পাশাপাশি কলকারীর অপেক্ষাকে সীমিত করতে পারে। তা শেষ হলে, আরেকটি প্রচেষ্টা সংযোগের সামর্থ্য না নেওয়ার আগে ক্লায়েন্টের সমর্থিত লাইফসাইকেলের মাধ্যমে অপারেশনটি বাতিল বা বন্ধ করুন।