কর্পোরেট প্রক্সি ও Windows অ্যাপ — WinINET, WinHTTP ও .NET-এ প্রক্সি রেজোলিউশন গুছিয়ে নেওয়া

«ব্রাউজার বাইরের সাইট খুলতে পারে, কিন্তু শুধু ব্যবসায়িক অ্যাপ বাইরের API-তে পৌঁছায় না।» «ডেভেলপমেন্ট মেশিনে চলে, কিন্তু গ্রাহক নেটওয়ার্কে টাইম আউট হয়।» «হাতে চালালে যোগাযোগ হয়, আর Windows সার্ভিস বানালেই ব্যর্থ হয়।» — কর্পোরেট প্রক্সি আছে এমন পরিবেশে ব্যবসায়িক অ্যাপ চালালে এ ধরনের পরামর্শ সবচেয়ে সাধারণের মধ্যে।

বেশিরভাগ ক্ষেত্রে কারণ প্রক্সি-সার্ভার আউটेजও নয়, অ্যাপ বাগও নয়। Windows-এ মানুষ যা «প্রক্সি সেটিং» বলে তার কয়েকটি আলাদা পরিবার আছে, আর কোন সেটিং কে পড়ে অ্যাপ (তার HTTP স্ট্যাক) ও চলমান অ্যাকাউন্ট অনুসারে আলাদা — সেই অমিল। ব্রাউজার যে সেটিং পড়ে, সার্ভিস যে পড়ে, আর .NET HttpClient যে পড়ে, প্রতিটি আলাদা জিনিস হতে পারে। সেই কাঠামো মাথায় এলে «ব্রাউজারে চলে, কিন্তু…» বিচ্ছিন্ন করা অবাক করা দ্রুত হয়ে যায়।

এই নিবন্ধ ছোট ও মাঝারি প্রতিষ্ঠানের IT কর্মী এবং Windows অ্যাপ ডেভেলপারদের লক্ষ্য করে। এটি এক ছবিতে তিন প্রক্সি-সেটিং পরিবার — WinINET, WinHTTP ও এনভায়রনমেন্ট ভেরিয়েবল — PAC ও WPAD স্বয়ংক্রিয় কনফিগারেশন, .NET Framework ও .NET (Core ও পরবর্তী)-এর প্রক্সি রেজোলিউশন পার্থক্য, প্রমাণীকরণ প্রক্সি (407), TLS পরিদর্শন, এবং ব্যবহারিক বিচ্ছিন্নকরণ বেঁধে দেয়। HttpClient তৈরির প্যাটার্ন ও টাইমআউট ডিজাইন নিজেই «HttpClient-কে using ব্লকে মুড়ে ফেলবেন না»-এ আছে, তাই এই নিবন্ধ প্রক্সি রেজোলিউশন-এ মনোযোগ দেয়।

1. আগে উপসংহার

• Windows প্রক্সি সেটিং এক জিনিস নয়; অন্তত তিন পরিবার আছে। (1) WinINET প্রতি-ব্যবহারকারী সেটিং (Settings অ্যাপের «Proxy» পাতা = পুরনো Internet Options), (2) WinHTTP মেশিন সেটিং (netsh winhttp), এবং (3) HTTP_PROXY / HTTPS_PROXY এনভায়রনমেন্ট ভেরিয়েবল। কোনটি পড়া হয় অ্যাপ পাশে ঠিক হয়।¹²
• Settings অ্যাপে যে «Proxy» দেখেন তা WinINET-এর প্রতি-ব্যবহারকারী সেটিং। ব্রাউজার ও ইন্টারঅ্যাকটিভ অ্যাপ পড়ে; Windows সার্ভিস পড়ে না। সার্ভিসে WinINET সমর্থিত নয়; সার্ভিস ব্যবহার WinHTTP-এর কাজ।¹³
• «হাতে চলে কিন্তু সার্ভিস হিসেবে নয়»-এর সবচেয়ে সাধারণ কারণ চলমান অ্যাকাউন্টের পার্থক্য। LocalSystem ও সার্ভিস অ্যাকাউন্ট অ্যাডমিনিস্ট্রেটর নিজের স্ক্রিনে কনফিগার করা প্রতি-ব্যবহারকারী প্রক্সি দেখতে পায় না।³⁴
• netsh winhttp set proxy স্থির সেটিং; PAC, স্বয়ংক্রিয় শনাক্তকরণ বা প্রক্সি প্রমাণীকরণ সামলায় না। মেশিন-প্রতি PAC বা WPAD কনফিগার করতে চাইলে netsh winhttp set advproxy পাশ লাগে।⁴²
• PAC ফল URL অনুসারে বদলায়। PAC ফাইলের FindProxyForURL ফাংশন URL ও হোস্ট নেয় এবং প্রক্সি তালিকা বা সরাসরি সংযোগ (DIRECT) ফেরায়। «ওই সাইট চলে, কিন্তু শুধু এই API চলে না» PAC শাখা হতে পারে।⁵⁶
• .NET (Core ও পরবর্তী)-এ HttpClient ডিফল্ট প্রক্সি এনভায়রনমেন্ট ভেরিয়েবল → Windows ব্যবহারকারী প্রক্সি সেটিং ক্রমে শুরু করে। HTTP_PROXY, HTTPS_PROXY বা ALL_PROXY-এর কোনোটি সংজ্ঞায়িত থাকলে OS সেটিংয়ের ওপর অগ্রাধিকার পায়, তাই «কেউ এনভায়রনমেন্ট ভেরিয়েবল রেখে গেছে» দুর্ঘটনা ঘটতে পারে।⁷
• .NET Framework-এর ডিফল্ট চলমান অ্যাকাউন্টের Internet Options, আর app.config-এ defaultProxy দিয়ে ওভাররাইড হয়। কনফিগারেশন-ফাইল সেটিং সিস্টেম সেটিংয়ের ওপর অগ্রাধিকার পায়।⁸⁹
• 407 প্রক্সি-প্রমাণীকরণ ত্রুটি; 401 (সার্ভার প্রমাণীকরণ) থেকে আলাদা। স্কিমে Negotiate, NTLM ও Basic আছে, আর .NET-এ ক্রেডেনশিয়াল DefaultProxyCredentials বা WebProxy.UseDefaultCredentials দিয়ে দেন। খেয়াল রাখুন সার্ভিস অ্যাকাউন্টের অধীনে «ডিফল্ট ক্রেডেনশিয়াল»-এর বিষয়বস্তু বদলায়।¹⁰¹¹¹²
• TLS-পরিদর্শন প্রক্সি শুধু অভ্যন্তরীণ CA সার্টিফিকেট বিতরণের সাথে সেট হিসেবে টেকে। যারা পায়নি, মেশিন ও রানটাইম সার্টিফিকেট-যাচাই ত্রুটি পায়। অ্যাপে যাচাই বন্ধ করে নয়, সার্টিফিকেট স্টোরে বিতরণ করে সমাধান করুন।¹³⁴

এক বাক্যে: যখনই বলেন «প্রক্সি সেটিং পরীক্ষা করেছি», সবসময় বলতে পারুন তিন পরিবারের কোনটি পরীক্ষা করেছেন, আর কোন অ্যাকাউন্ট থেকে — সেটাই এই নিবন্ধের বিষয়।

2. Windows-এ «প্রক্সি সেটিং»-এর তিন পরিবার আছে

আগে, সামগ্রিক মানচিত্র। Windows অ্যাপ কর্পোরেট প্রক্সি খুঁজতে যে পথ ব্যবহার করে সেগুলো এই তিন পরিবারে পড়ে।

(1) মানুষ সাধারণত যা «Windows প্রক্সি সেটিং» চেনে; সার WinINET কনফিগারেশন। ঐতিহাসিকভাবে Internet Explorer-এর Internet Options, আর ডিফল্টে প্রতি ব্যবহারকারী সংরক্ষিত।⁴

(2) সার্ভিসের মতো প্রসঙ্গের জন্য প্রতি-মেশিন ডিফল্ট যেখানে «সাইন-ইন ব্যবহারকারী নেই»। (3) মূলত ক্রস-প্ল্যাটফর্ম জগত থেকে আসা টুলের রীতি; Windows-এ .NET (Core ও পরবর্তী) ও curl ইত্যাদিও পড়ে।⁷

গুরুত্বপূর্ণ বিষয় কোন পরিবার পড়া হয় সেটিং পাশে নয়, অ্যাপ পাশে ঠিক হয়। অ্যাপ ভিতরে WinINET ব্যবহার করলে (1) পড়ে; WinHTTP হলে (2) (বা অ্যাপ-নির্দিষ্ট ওভাররাইড); .NET (Core ও পরবর্তী) হলে (3) তারপর (1)। তাই সাধারণত «প্রক্সি সেটিং ঠিক তবু সংযোগ হয় না» নয়; বাস্তব «অ্যাপ যে পরিবার পড়ছিল তা আপনি যে পরিবার পরীক্ষা করেছেন তার থেকে আলাদা পরিবার ছিল»।

flowchart TB
    accTitle: Windows প্রক্সি সেটিংয়ের তিন পরিবার
    accDescr: WinINET প্রতি-ব্যবহারকারী Settings ও Internet Options, WinHTTP netsh দিয়ে মেশিন ডিফল্ট, আর এনভায়রনমেন্ট ভেরিয়েবল প্রসেস-পরিধি। কোন পরিবার পড়া হয় সেটিং পাশ নয়, অ্যাপ ঠিক করে
    fam{"কোন পরিবার?"}
    fam --> wininet["WinINET প্রতি-ব্যবহারকারী সেটিং"]
    fam --> winhttp["WinHTTP মেশিন সেটিং"]
    fam --> env["HTTP_PROXY ও সঙ্গীরা"]
    wininet -.-> r1["ব্রাউজার ও ডেস্কটপ অ্যাপ"]
    winhttp -.-> r2["সার্ভিস ও কিছু OS অংশ"]
    env -.-> r3[".NET Core+ ও curl"]

চিত্র 1: তিন পরিবার পাশাপাশি বসে। অ্যাপ বেছে নেয় কোনটি পড়বে।

Group Policy «Make proxy settings per-machine (rather than per-user)» চালু করলে (1)-কে প্রতি-মেশিন করে প্রতিটি ব্যবহারকারীতে একই সেটিং প্রয়োগ করতে পারেন। MDM (Intune ইত্যাদি) দিয়ে NetworkProxy CSP-এ ডিভাইস-প্রতি কনফিগার করতে পারেন।⁴

3. WinINET ও WinHTTP — ইন্টারঅ্যাকটিভ অ্যাপের জন্য ও সার্ভিসের জন্য

3.1. ভূমিকার পার্থক্য

WinINET ও WinHTTP দুটোই Windows ইনবক্স HTTP ক্লায়েন্ট স্ট্যাক, কিন্তু আলাদা ব্যবহার ধরে।

• WinINET: ইন্টারঅ্যাকটিভ ডেস্কটপ অ্যাপের জন্য। ব্যবহারকারীর Internet Options (প্রক্সি, কুকি, ক্রেডেনশিয়াল ক্যাশ) স্বয়ংক্রিয় উত্তরাধিকার নেয় এবং দরকার হলে ক্রেডেনশিয়াল-এন্ট্রি UIও দেখাতে পারে। সার্ভিস বা সার্ভিস-সদৃশ প্রসেসে ব্যবহার সমর্থিত নয়।¹
• WinHTTP: সার্ভিস ও সার্ভার পাশের জন্য। সার্ভিস অ্যাকাউন্টের অধীনে চলা, থ্রেড ইমপারসোনেশন ও সেশন বিচ্ছিন্নতা সমর্থন করে; বিনিময়ে ব্যবহারকারীর ব্রাউজার সেটিং, কুকি বা ক্রেডেনশিয়াল ভাগ করে না। UIও দেখায় না।³

Microsoft-এর নিজের নির্দেশনাও সমান স্পষ্ট: «WinINET ব্যবহার করুন যতক্ষণ না আপনি সার্ভিসের ভিতরে, বা সেশন বিচ্ছিন্নতা ও ইমপারসোনেশন লাগে এমন সার্ভিস-সদৃশ প্রসেসে চলছেন» — অন্যভাবে, সার্ভিস হলে WinHTTP ব্যবহার করুন।¹

flowchart TB
    accTitle: ইন্টারঅ্যাকটিভ অ্যাপের জন্য WinINET, সার্ভিসের জন্য WinHTTP
    accDescr: WinINET সাইন-ইন ব্যবহারকারীর Internet Options উত্তরাধিকার নেয় এবং সার্ভিসে সমর্থিত নয়। WinHTTP UI ছাড়া সার্ভিস অ্যাকাউন্টের অধীনে চলে এবং ব্যবহারকারীর ব্রাউজার সেটিং ভাগ করে না
    q{"ইন্টারঅ্যাকটিভ ডেস্কটপ অ্যাপ?"}
    q -->|"হ্যাঁ"| ie["WinINET"]
    q -->|"সার্ভিস বা সার্ভিস-সদৃশ"| wh["WinHTTP"]
    ie -.-> ieNote["ব্যবহারকারীর Internet Options পড়ে"]
    wh -.-> whNote["মেশিন সেটিং, UI নেই"]

চিত্র 2: ইন্টারঅ্যাকটিভ অ্যাপ WinINET ব্যবহার করে। সার্ভিস WinHTTP ব্যবহার করে।

3.2. মৌলিক netsh winhttp অপারেশন

WinHTTP-এর মেশিন-ডিফল্ট প্রক্সি netsh দিয়ে চালানো হয়।²

:: Display the current WinHTTP proxy settings
netsh winhttp show proxy

:: Set a static proxy (with a bypass list)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Import the Internet Options (WinINET) settings
netsh winhttp import proxy source=ie

:: Return to the default (DIRECT)
netsh winhttp reset proxy

এখানে দুটি সীমাবদ্ধতা মনে রাখুন।

1. netsh winhttp set proxy স্থির সেটিং। প্রক্সি স্বয়ংক্রিয়-শনাক্তকরণ, PAC URL নির্দিষ্ট করা, বা প্রক্সি প্রমাণীকরণ কোনোটাই সামলায় না।⁴
2. import proxy source=ie সেই মুহূর্তের স্থির সেটিংয়ের কপি মাত্র; পরে Internet Options পাশের পরিবর্তন অনুসরণ করে না। PAC বা স্বয়ংক্রিয়-শনাক্তকরণসহ প্রতি-মেশিন কনফিগারেশন লাগলে JSON-রূপ বিস্তারিত সেটিং (Proxy, ProxyBypass, AutoconfigUrl, AutoDetect) netsh winhttp set advproxy দিয়ে কনফিগার করুন।²

3.3. সবচেয়ে সাধারণ ফাঁদ: সার্ভিস ব্যবহারকারীর IE সেটিং পড়ে না

সাইটে সবচেয়ে বেশি দেখা প্যাটার্ন, সময়ক্রমে, এমন দেখায়।

1. ডেভেলপার নিজের PC-তে টুল চালায় → তার প্রতি-ব্যবহারকারী প্রক্সি সেটিং (1) কার্যকর হয় এবং চলে
2. প্রোডাকশনে LocalSystem-এর অধীনে Windows সার্ভিস (Windows সার্ভিস কীভাবে বানান ও চালান) হিসেবে রেসিডেন্ট রেখে দেওয়া হয়
3. LocalSystem থেকে দৃশ্যমান সেটিং আলাদা জিনিস (প্রতি-ব্যবহারকারী সেটিং অদৃশ্য, আর WinHTTP মেশিন সেটিং অকনফিগারড = DIRECT) → বাইরের API-তে সরাসরি সংযোগ চেষ্টা করে এবং টাইম আউট হয়

«একই মেশিন তবু চলে না» নয়; একই মেশিনেও আলাদা চলমান অ্যাকাউন্ট মানে আলাদা দৃশ্যমান প্রক্সি সেটিংয়ের সেট। যে প্রসেস কোনো ব্যবহারকারী সাইন ইন না থাকলেও যোগাযোগ করে, সঠিক পদ্ধতি প্রতি-মেশিন সেটিং সেই রূপে প্রস্তুত করা যা সেই প্রসেসের HTTP স্ট্যাক সত্যি পড়ে। WinHTTP ব্যবহার করা নেটিভ অ্যাপ বা Windows উপাদানের জন্য netsh WinHTTP সেটিং কার্যকর।⁴ অন্যদিকে .NET (Core ও পরবর্তী)-এ HttpClient WinHTTP-এর মেশিন সেটিং পড়ে না (অধ্যায় 5 দেখুন), তাই .NET সার্ভিসের জন্য সিস্টেম এনভায়রনমেন্ট ভেরিয়েবল (HTTPS_PROXY ইত্যাদি) সেট করুন বা অ্যাপ সেটিং থেকে HttpClientHandler.Proxy স্পষ্ট দিন।

দুর্ঘটনা অন্য দিকেও ঘটে। কর্পোরেট নেটওয়ার্ক ও বাইরের মধ্যে ঘোরা ল্যাপটপে netsh winhttp set proxy দিয়ে স্থির প্রক্সি পুড়িয়ে দিলে সেই প্রক্সি কোম্পানির বাইরে পৌঁছানো যায় না এবং যোগাযোগ সম্পূর্ণ মরে। মেশিন-স্থির সেটিংকে এমন সার্ভারের উপায় ধরুন যাদের নেটওয়ার্ক কনফিগারেশন বদলায় না।⁴

flowchart TB
    accTitle: সার্ভিস ব্যবহারকারীর IE সেটিং কেন দেখে না
    accDescr: ডেভেলপার চালালে প্রতি-ব্যবহারকারী WinINET সেটিং পড়ে এবং চলে। LocalSystem হিসেবে সেই সেটিং অদৃশ্য। নেটিভ WinHTTP অ্যাপ তখন অকনফিগারড মেশিন সেটিং (DIRECT) অনুসরণ করে। .NET Core+ সার্ভিস তবু এনভায়রনমেন্ট ভেরিয়েবল বা স্পষ্ট handler.Proxy ব্যবহার করে এবং netsh winhttp-এ যায় না
    dev["ব্যবহারকারী হিসেবে হাতে চালান"] --> ok["WinINET প্রতি-ব্যবহারকারী সেটিং প্রযোজ্য"]
    svc["LocalSystem হিসেবে Windows সার্ভিস"] --> miss["প্রতি-ব্যবহারকারী সেটিং অদৃশ্য"]
    miss --> stack{"কোন HTTP স্ট্যাক?"}
    stack -->|"WinHTTP"| direct["WinHTTP অকনফিগারড = DIRECT"]
    stack -->|".NET Core+"| env["এনভায়রনমেন্ট ভেরিয়েবল বা handler.Proxy"]
    direct --> fail["বাইরের API টাইম আউট"]

চিত্র 3: একই মেশিন, আলাদা অ্যাকাউন্ট, আলাদা দৃশ্যমান প্রক্সি সেটিংয়ের সেট।

4. PAC ও WPAD — «স্বয়ংক্রিয় কনফিগারেশন» আসলে কী

4.1. PAC ফাইল ও FindProxyForURL

PAC (Proxy Auto-Configuration) ফাইল JavaScript (ECMAScript) যা হিসাব করে «এই URL-এর জন্য কোন প্রক্সি ব্যবহার করব», আর তাতে সবসময় FindProxyForURL(url, host) নামের ফাংশন থাকে। ফাংশন ব্যবহারযোগ্য প্রক্সির তালিকা ফেরায়, বা বিশেষ রিটার্ন মান (DIRECT) যার অর্থ প্রক্সি ছাড়া সরাসরি সংযোগ ঠিক।⁵

function FindProxyForURL(url, host) {
    // Internal domains and private addresses go direct
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Everything else goes through a proxy. Fall back to the next if the first is unavailable
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

দুটি ব্যবহারিক পরিণতি আসে।

• প্রক্সি রেজোলিউশন URL অনুসারে করতে হয়। PAC URL (হোস্ট) অনুসারে আলাদা প্রক্সি বা সরাসরি সংযোগ ফেরাতে পারে বলে WinHTTP-এর স্বয়ংক্রিয়-প্রক্সি ফিচারও অনুরোধ URL পাস করে প্রতিবার জিজ্ঞাসা করার জন্য ডিজাইন।⁶ «ব্রাউজার অন্য সাইট দেখতে পারে» প্রমাণ নয় যে সমস্যা API একই পথ নেয়।
• DIRECT «প্রক্সি ছাড়া যান» নির্দেশ। অভ্যন্তরীণ হওয়া উচিত ট্রাফিক প্রক্সি লগে কখনো না দেখা গেলে আগে সন্দেহ করুন PAC DIRECT ফিরিয়েছে (বা বাইপাস তালিকায় মিলেছে)।

4.2. WPAD দিয়ে স্বয়ংক্রিয় শনাক্তকরণ

«Automatically detect settings» চালু করলে মেশিন WPAD (Web Proxy Auto-Discovery) প্রোটোকল দিয়ে PAC ফাইলের অবস্থান খোঁজে। সাধারণ কনফিগারেশনে DHCP PAC URL দেয়, বা DNS দিয়ে wpad নামের হোস্ট খোঁজা হয় এবং PAC http://wpad/wpad.dat-এর মতো URL থেকে ডাউনলোড হয়।¹⁴

অন্যভাবে, «স্বয়ংক্রিয় শনাক্তকরণ» জাদু নয়; এটি এমন ব্যবস্থা যা শুধু সেই নেটওয়ার্কে কাজ করে যেখানে DHCP/DNS-এ আগেই WPAD ব্যবস্থা আছে। এমন ব্যবস্থাহীন নেটওয়ার্কে শুধু স্বয়ংক্রিয় শনাক্তকরণ চালু করা শনাক্তকরণ ব্যর্থতার অপেক্ষার সময় যোগ করে।

flowchart TB
    accTitle: PAC URL অনুসারে প্রক্সি রেজোলিভ করে, WPAD শুধু PAC খুঁজে
    accDescr: FindProxyForURL URL ও হোস্ট নেয় এবং প্রক্সি তালিকা বা DIRECT ফেরায়। WPAD শুধু DHCP বা DNS দিয়ে PAC খুঁজে। PAC মূল্যায়ন করতে না পারা ক্লায়েন্ট স্থির প্রক্সি বা এনভায়রনমেন্ট ভেরিয়েবলে পড়ে
    url["অনুরোধ URL"] --> pac["FindProxyForURL"]
    pac -->|"প্রক্সি তালিকা"| via["প্রক্সি দিয়ে যান"]
    pac -->|"DIRECT"| dir["প্রক্সি ছাড়া সংযোগ"]
    wpad["DHCP বা DNS দিয়ে WPAD"] -.-> pac
    nopac["ক্লায়েন্ট PAC মূল্যায়ন করতে পারে না"] -.-> fb["স্থির সেটিং বা এনভায়রনমেন্ট ভেরিয়েবল"]

চিত্র 4: PAC URL অনুসারে সিদ্ধান্ত নেয়। WPAD শুধু PAC ফাইল খুঁজে।

4.3. PAC মূল্যায়ন করতে না পারা ক্লায়েন্ট কীভাবে আচরণ করে

প্রতিটি ক্লায়েন্ট PAC মূল্যায়ন করতে পারে না।

• netsh winhttp set proxy-এর স্থির সেটিং PAC মূল্যায়ন করে না।⁴
• HTTP_PROXY এনভায়রনমেন্ট-ভেরিয়েবল শৈলী ব্যবহার করা টুল নিয়মত স্থির প্রক্সি URLই লিখতে পারে (PAC URL লেখার জায়গা নেই)।⁷
• সরাসরি WinHTTP ব্যবহার করা নেটিভ অ্যাপের জন্য সেশন কীভাবে খোলা হয়েছে তার ওপর নির্ভর করে। Windows 8.1 ও পরবর্তীতে WinHttpOpen দিয়ে WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY নির্দিষ্ট করে খোলা অ্যাপ WinHTTP-কে সিস্টেম/ব্যবহারকারী প্রক্সি সেটিং (WPAD/PACসহ) অনুরোধ-প্রতি স্বয়ংক্রিয় রেজোলিভ করতে দেয়।¹⁵ পুরনো WINHTTP_ACCESS_TYPE_DEFAULT_PROXY (৮.১ থেকে অবচিত) ইত্যাদি দিয়ে খোলা হলে স্বয়ংক্রিয় প্রক্সি HTTP স্ট্যাকে একীভূত নয়, আর অ্যাপকে নিজে WinHttpGetProxyForUrl ডেকে ফল অনুরোধে প্রয়োগ করতে হয়। অন্যভাবে, পুরনো ইমপ্লিমেন্টেশনে PAC থাকলেও অব্যবহৃত থাকতে পারে।⁵

«ব্রাউজার PAC দিয়ে সঠিক প্রক্সিতে যায়, কিন্তু ব্যবসায়িক অ্যাপ PAC পড়ে না এবং সরাসরি সংযোগ চেষ্টা করে ব্যর্থ হয়» — এটি আরও একটি প্রধান অমিল। PAC-চালিত নেটওয়ার্কে PAC পড়তে না পারা ক্লায়েন্টের জন্য ফলব্যাক — স্থির সেটিং বা এনভায়রনমেন্ট ভেরিয়েবল — ঠিক করতে হয়।

5. .NET প্রক্সি রেজোলিউশন — Framework ও Core ও পরবর্তী আলাদা জিনিস

.NET অ্যাপ কোন প্রক্সি সেটিং পড়ে .NET Framework ও .NET (Core ও পরবর্তী)-এর মধ্যে ডিফল্টে আলাদা। দুটো মেশালে আপনি .NET 8 অ্যাপকে Framework-যুগের জ্ঞান দিয়ে খুঁজবেন এবং মিস করবেন।

5.1. .NET Framework — ডিফল্ট Internet Options, defaultProxy দিয়ে ওভাররাইড

.NET Framework-এ HttpWebRequest ও তার ওপর বসা HttpClient স্পষ্ট Proxy না দিলে ডিফল্ট প্রক্সি ব্যবহার করে। ডিফল্ট প্রক্সি সিস্টেম Internet সেটিং (চলমান অ্যাকাউন্টের WinINET সেটিং) ও কনফিগারেশন ফাইলের সংমিশ্রণে ঠিক হয়, আর কনফিগারেশন-ফাইল সেটিং অগ্রাধিকার পায়।⁸

এই ডিফল্ট app.config (বা machine.config)-এর system.net/defaultProxy এলিমেন্ট দিয়ে নিয়ন্ত্রণ করতে পারেন।⁹

<configuration>
  <system.net>
    <!-- useDefaultCredentials: whether to send default credentials to an authenticating proxy -->
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy usesystemdefault="true"
             proxyaddress="http://proxy.example.co.jp:8080"
             bypassonlocal="true" />
      <bypasslist>
        <add address="[a-z]+\.example\.co\.jp$" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

defaultProxy এলিমেন্ট খালি রাখলে সিস্টেম (Internet Options) সেটিং ব্যবহৃত হয়; proxyaddress ইত্যাদি লিখলে সেগুলো অগ্রাধিকার পায়। প্রোগ্রাম থেকে একই ডিফল্ট WebRequest.DefaultWebProxy দিয়ে বদলাতে পারেন।⁹⁸

অধ্যায় ৩.৩-এর ফাঁদ এখানেও প্রযোজ্য। ডিফল্ট «চলমান অ্যাকাউন্টের Internet Options» বলে সার্ভিস অ্যাকাউন্টের অধীনে চলা .NET Framework অ্যাপ অ্যাডমিনিস্ট্রেটরের ডেস্কটপে দৃশ্যমান সেটিং থেকে আলাদা (সাধারণত খালি) সেট পড়ে।

5.2. .NET (Core ও পরবর্তী) — আগে এনভায়রনমেন্ট ভেরিয়েবল, তারপর OS ব্যবহারকারী সেটিং

.NET (Core ও পরবর্তী)-এ HttpClient-এর স্ট্যাটিক প্রপার্টি HttpClient.DefaultProxy আছে। হ্যান্ডলার স্পষ্ট প্রক্সি না দিলে প্রতিটি HttpClient ইনস্ট্যান্স তা ব্যবহার করে। Windows-এ আরম্ভ নিয়ম «এনভায়রনমেন্ট ভেরিয়েবল পড়ুন, আর সংজ্ঞায়িত না থাকলে ব্যবহারকারী প্রক্সি সেটিং পড়ুন»।⁷

ব্যবহৃত এনভায়রনমেন্ট ভেরিয়েবল নিম্নরূপ।⁷

তিন বিষয় খেয়াল করুন।

• HTTP_PROXY, HTTPS_PROXY বা ALL_PROXY-এর কোনোটি সংজ্ঞায়িত থাকলে OS-পাশের প্রক্সি সেটিংয়ের ওপর অগ্রাধিকার পায়। শুধু NO_PROXY সংজ্ঞায়িত করলে এনভায়রনমেন্ট ভেরিয়েবল থেকে প্রক্সি কনফিগার হয় না, আর Windows-এ OS ব্যবহারকারী প্রক্সি সেটিং চলতে থাকে। পুরনো পরীক্ষার পর HTTPS_PROXY সিস্টেম এনভায়রনমেন্ট ভেরিয়েবল রেখে যাওয়া, বা CI/CD টেমপ্লেট ইনজেক্ট করা, এমন «অদৃশ্য সেটিং» দুর্ঘটনার প্রজননক্ষেত্র।
• NO_PROXY ওয়াইল্ডকার্ড (*) সমর্থন করে না। সাবডোমেইন মেলাতে অগ্রণী বিন্দু দিন (.example.com www.example.com-এ মেলে কিন্তু example.com নিজেতে নয়)।⁷
• নন-Windows (Linux কন্টেইনার ইত্যাদি)-এ এনভায়রনমেন্ট ভেরিয়েবল অসংজ্ঞায়িত থাকলে প্রক্সি ছাড়া আরম্ভ হয়। একই অ্যাপের ডিফল্ট আচরণ Windows ও Linux-এর মধ্যে বদলানো কন্টেইনার-মাইগ্রেশন সময়ে নিশ্চিত করুন।⁷

5.3. স্পষ্ট নির্দিষ্টকরণ — HttpClientHandler.Proxy ও UseProxy

যেকোনো রানটাইমে সর্বোচ্চ অগ্রাধিকার হ্যান্ডলারে স্পষ্ট নির্দিষ্টকরণ। HttpClientHandler.Proxy নির্দিষ্ট করা OS সেটিং ও কনফিগারেশন ফাইলের ওপর অগ্রাধিকার পায়, আর UseProxy = false কোনো প্রক্সি ব্যবহার করে না।¹⁴

using System.Net;

// Use a proxy read from app settings explicitly
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // On an authenticating proxy, respond with the running account's credentials
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// A client that never uses a proxy (for direct internal APIs)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

স্পষ্ট নির্দিষ্টকরণ না থাকলে এবং OS সেটিং অনুসরণ করলে স্থানীয় গন্তব্যের স্বয়ংক্রিয় বাইপাসের নিয়ম আছে। বিন্দুহীন ফ্ল্যাট নাম, লুপব্যাক ঠিকানা, মেশিনের নিজের ডোমেইন সাফিক্সে মেলা গন্তব্য ইত্যাদি «স্থানীয়» ধরা হতে পারে।¹⁴ «IP ঠিকানা দিলে আচরণ বদলায়» বা «FQDN ব্যবহার করলে হঠাৎ প্রক্সি দিয়ে যেতে শুরু করে» এমন ঘটনা এই বিচার থেকে হতে পারে।

অগ্রাধিকার ক্রম নিম্নরূপ।

flowchart TB
    accTitle: Framework বনাম Core ও পরবর্তীতে ডিফল্ট প্রক্সি রেজোলিউশন
    accDescr: স্পষ্ট HttpClientHandler.Proxy সবসময় জিতে। Framework তারপর app.config defaultProxy ও চলমান অ্যাকাউন্টের Internet Options ব্যবহার করে। Core ও পরবর্তী HttpClient.DefaultProxy অ্যাসাইনমেন্ট, তারপর এনভায়রনমেন্ট ভেরিয়েবল, তারপর Windows ব্যবহারকারী প্রক্সি সেটিং
    expl["স্পষ্ট handler.Proxy"] --> done["সেই প্রক্সি ব্যবহৃত হয়"]
    noexpl["স্পষ্ট Proxy নেই"] --> fw{"কোন রানটাইম?"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["চলমান অ্যাকাউন্টের Internet Options"]
    fw -->|"Core ও পরবর্তী"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY ও সঙ্গীরা"]
    ev --> user["Windows ব্যবহারকারী প্রক্সি সেটিং"]

চিত্র 5: স্পষ্ট নির্দিষ্টকরণ সবসময় জিতে। ডিফল্ট পথ রানটাইম অনুসারে আলাদা।

6. প্রমাণীকরণ প্রক্সি — 407 প্রক্সির প্রমাণীকরণ ত্রুটি

6.1. 407-কে 401-এর সাথে গুলিয়ে ফেলবেন না

প্রমাণীকরণ চাওয়া প্রক্সি দিয়ে যেতে চেষ্টা করলে প্রক্সি স্ট্যাটাস কোড 407 (Proxy Authentication Required) এবং উপলব্ধ স্কিম তালিকাভুক্ত করে Proxy-Authenticate হেডার ফেরায়। সেটা গন্তব্য সার্ভারের প্রমাণীকরণ চাহিদা (401 ও WWW-Authenticate) থেকে আলাদা; ক্রেডেনশিয়াল কাকে দেবেন এবং কোথায় কনফিগার করবেন দুটোই আলাদা।¹⁰

flowchart TB
    accTitle: 407 প্রক্সি, 401 গন্তব্য সার্ভার
    accDescr: 407 ও Proxy-Authenticate প্রক্সি থেকে আসে। 401 ও WWW-Authenticate গন্তব্য সার্ভার থেকে আসে। ক্রেডেনশিয়াল ও কনফিগার স্থান আলাদা
    req["আউটবাউন্ড অনুরোধ"] --> who{"কে প্রমাণীকরণ চায়?"}
    who -->|"প্রক্সি"| e407["407 + Proxy-Authenticate"]
    who -->|"গন্তব্য"| e401["401 + WWW-Authenticate"]
    e407 -.-> cred["DefaultProxyCredentials"]

চিত্র 6: 407 প্রক্সি প্রমাণীকরণ। 401 সার্ভার প্রমাণীকরণ।

স্কিমে Basic আছে, যা ব্যবহারকারীর নাম ও পাসওয়ার্ড যেমন আছে তেমন পাঠায়, আর Negotiate (Kerberos/NTLM)-এর মতো চ্যালেঞ্জ/রেসপন্স স্কিম। চ্যালেঞ্জ/রেসপন্স স্কিমে পাসওয়ার্ড নিজে নেটওয়ার্কে যায় না, আর প্রমাণীকরণ কয়েক বিনিময়ে সম্পূর্ণ হয়।¹⁰ কোন স্কিমে «পড়ে» তার যন্ত্র «চিত্রসহ NTLM ও Kerberos»-এ বিস্তারিত।

6.2. .NET-এ ক্রেডেনশিয়াল কীভাবে দেবেন

OS সেটিং থেকে আসা ডিফল্ট প্রক্সি ব্যবহার করতে চাইলে এবং শুধু প্রমাণীকরণ পার করতে চাইলে HttpClientHandler.DefaultProxyCredentials ব্যবহার করুন। এগুলো সেই ডিফল্ট প্রক্সিতে পাঠানো ক্রেডেনশিয়াল যখন UseProxy = true ও Proxy = null (= সিস্টেম-ডিফল্ট প্রক্সি)।¹¹

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // The default. Combined with a null Proxy, this uses the system-default proxy
    Proxy = null,
    // Respond to 407 with the credentials of the running account (signed-in user or service account)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

প্রক্সি স্পষ্ট নির্দিষ্ট করলে ক্রেডেনশিয়াল WebProxy পাশে রাখুন। অনেক ক্লায়েন্ট পরিস্থিতিতে সুপারিশ ব্যক্তিগত ব্যবহারকারীর নাম ও পাসওয়ার্ডের বদলে সাইন-ইন ব্যবহারকারীর ডিফল্ট ক্রেডেনশিয়াল ব্যবহার, আর WebProxy.UseDefaultCredentials = true সেটাই।¹²

6.3. সার্ভিস-অ্যাকাউন্ট 407 সমস্যা

এখানেও চলমান অ্যাকাউন্ট গুরুত্বপূর্ণ। «ডিফল্ট ক্রেডেনশিয়াল» মানে সেই প্রসেস চালাচ্ছে যে অ্যাকাউন্ট তার ক্রেডেনশিয়াল। ইন্টারঅ্যাকটিভ ব্যবহারকারী হিসেবে চালালে প্রক্সি প্রমাণীকরণ সেই ব্যবহারকারী হিসেবে; LocalSystem সার্ভিস হিসেবে চালালে কম্পিউটার অ্যাকাউন্ট হিসেবে।

• প্রক্সি Active Directory দিয়ে ব্যবহারকারী প্রমাণীকরণ করলে কম্পিউটার অ্যাকাউন্ট বা লোকাল অ্যাকাউন্ট প্রমাণীকরণ করতে পারে না, আর অ্যাপ সার্ভিস বানালেই 407 চলতে থাকে
• উল্টো, কিছু পরিবেশে সার্ভিসের জন্য প্রক্সি পাশে প্রমাণীকরণ ছাড় আছে (সোর্স IP বা অ্যাকাউন্ট দিয়ে)

তাই 407 তদন্ত «অ্যাপের সেটিং»-এ একা শেষ হয় না; এটি অবকাঠামো পাশের ডিজাইন পরীক্ষার সাথে সেট: প্রক্সি চলমান অ্যাকাউন্টকে প্রমাণীকরণ করতে পারে কি না। সার্ভিস বানাতে যাওয়া অ্যাপের জন্য ডিজাইন সময়ে ঠিক করুন: ডোমেইন সার্ভিস অ্যাকাউন্ট (gMSA ইত্যাদি)-এর অধীনে চালাবেন, প্রক্সি পাশে প্রমাণীকরণ ছাড় দেবেন, নাকি প্রমাণীকরণ না চাওয়া অভ্যন্তরীণ রিলে প্রক্সি দাঁড় করাবেন।

HTTP_PROXY=http://user:pass@proxy:8080-এর মতো এনভায়রনমেন্ট ভেরিয়েবলে ক্রেডেনশিয়াল এম্বেড করার শৈলীও আছে⁷, কিন্তু তখন সাদা পাঠ্য পাসওয়ার্ড এনভায়রনমেন্ট ভেরিয়েবলে (= প্রসেস তথ্য) খোলা, তাই স্থায়ী পরিচালনার জন্য সুপারিশ নয়।

7. HTTPS ও প্রক্সি — CONNECT টানেল ও TLS পরিদর্শন

7.1. HTTPS প্রক্সি দিয়ে «টানেল» হিসেবে যায়

HTTPS-এর জন্য প্রক্সি ব্যবহার করলে ক্লায়েন্ট আগে প্রক্সিকে CONNECT destination-host:443 অনুরোধ পাঠায়, আর প্রক্সি TCP টানেল খোলে। সফল হলে প্রক্সি 200 ফেরায়, তারপর ক্লায়েন্ট ও গন্তব্য সার্ভার সেই টানেলের ভিতরে TLS হ্যান্ডশেক করে। টানেল না খুললে প্রক্সি 407 (প্রমাণীকরণ প্রয়োজন), 502 ইত্যাদি ফেরায়।¹⁶

এই মডেলে প্রক্সি টানেলের বিষয়বস্তু (এনক্রিপ্টেড HTTPS) পড়তে পারে না। প্রক্সি লগে গন্তব্য হোস্ট নাম ও সংযোগ সফল কি না থাকে; URL পথ দেখা যায় না — সেটাই «পাস-থ্রু» প্রক্সির আচরণ।

flowchart TB
    accTitle: প্রক্সি দিয়ে HTTPS CONNECT টানেল
    accDescr: ক্লায়েন্ট প্রক্সিকে CONNECT পাঠায়, প্রক্সি TCP টানেল খুলে 200 ফেরায়, তারপর ক্লায়েন্ট ও গন্তব্য টানেলের ভিতরে TLS হ্যান্ডশেক করে। প্রক্সি লগ হোস্ট দেখে, URL পথ নয়
    cli["ক্লায়েন্ট"] -->|"CONNECT host:443"| px["প্রক্সি"]
    px -->|"200 ও TCP টানেল"| dest["গন্তব্য"]
    dest -->|"টানেলের ভিতরে TLS"| cli
    px -.-> log["লগ: শুধু হোস্ট ও সাফল্য"]

চিত্র 7: পাস-থ্রু প্রক্সি হোস্ট দেখে, এনক্রিপ্টেড পথ নয়।

7.2. TLS-পরিদর্শন প্রক্সি ও সার্টিফিকেট ত্রুটি

অন্যদিকে নিরাপত্তা-পণ্য প্রক্সিতে TLS-পরিদর্শন (SSL ডিক্রিপশন, break and inspect) ধরন আছে যা TLS শেষ করে, বিষয়বস্তু পরিদর্শন করে, আর ফরোয়ার্ড করার আগে পুনঃএনক্রিপ্ট করে। এই স্কিমে ক্লায়েন্টকে দেখানো সার্ভার সার্টিফিকেট আসল নয়; প্রক্সির নিজের CA দিয়ে পুনঃস্বাক্ষরিত সার্টিফিকেট দিয়ে বদলানো হয়।¹³

তাই এই কনফিগারেশন টিকার ভিত্তি «প্রক্সির CA সার্টিফিকেট প্রতিটি ক্লায়েন্টের বিশ্বস্ত রুটে বিতরণ হয়েছে»। যে মেশিন পায়নি, বা যে রানটাইম Windows সার্টিফিকেট স্টোর দেখে না (নিজের ট্রাস্ট স্টোর আছে এমন টুল), সার্টিফিকেট-যাচাই ত্রুটি পায়। .NET-এ সাধারণত AuthenticationException মুড়ানো HttpRequestException হিসেবে ওঠে («the remote certificate is invalid» ধরনের বার্তা)।

সংশোধনের নীতি নিম্নরূপ।

• অভ্যন্তরীণ CA সার্টিফিকেট লোকাল কম্পিউটারের «Trusted Root Certification Authorities» স্টোরে বিতরণ করুন। ব্যবহারকারী স্টোর ও কম্পিউটার স্টোরের ভাগ «ব্যবহারিক Windows সার্টিফিকেট স্টোর»-এ আছে।
• কোডে সার্টিফিকেট যাচাই বন্ধ করবেন না। ServerCertificateCustomValidationCallback থেকে সবসময় true ফেরানো ওয়ার্কঅ্যারাউন্ড বাইরের নেটওয়ার্কে গেলেই ম্যান-ইন-দ্য-মিডল ধরতে না পারা দুর্বল অ্যাপ হয়ে যায়।
• সার্টিফিকেট-পিন করা ট্রাফিক প্রথমেই পরিদর্শনযোগ্য নয়। কিছু Windows উপাদানের মতো নির্দিষ্ট Microsoft সার্টিফিকেট যাচাই করা সংযোগ প্রক্সি সার্টিফিকেট বদলালেই ব্যর্থ হয়, আর ছাড় ছাড়া ওয়ার্কঅ্যারাউন্ড নেই।⁴ Microsoft 365-এর মতো SaaS-গন্তব্য ট্রাফিকের জন্য Microsoft নিজেই নেটওয়ার্ক-স্তর ডিক্রিপশন ও পরিদর্শন থেকে ছাড় সুপারিশ করে।¹³

«সব অভ্যন্তরীণ সাইট দেখা যায়, কিন্তু শুধু নির্দিষ্ট ক্লাউড সার্ভিস অ্যাপে সার্টিফিকেট ত্রুটি দেয়» লক্ষণ আগে TLS-পরিদর্শন ছাড় তালিকা ও পিনিংয়ের সংমিশ্রণ সন্দেহ করাবে।

flowchart TB
    accTitle: TLS-পরিদর্শন প্রক্সি সার্টিফিকেট পুনঃস্বাক্ষর করে
    accDescr: প্রক্সি TLS শেষ করে, বিষয়বস্তু পরিদর্শন করে, আর নিজের CA দিয়ে পুনঃস্বাক্ষরিত সার্টিফিকেট দেখায়। যাচাই তখনই টেকে যখন সেই CA বিশ্বস্ত রুটে থাকে। কোডে যাচাই বন্ধ করবেন না
    real["আসল সার্ভার সার্টিফিকেট"] --> px["TLS-পরিদর্শন প্রক্সি"]
    px --> fake["প্রক্সি CA দিয়ে পুনঃস্বাক্ষরিত"]
    fake --> client["ক্লায়েন্ট যাচাই"]
    client -->|"CA বিশ্বস্ত রুটে"| ok["সফল"]
    client -->|"CA নেই"| err["সার্টিফিকেট ত্রুটি"]
    err -.-> fix["CA স্টোরে বিতরণ করুন"]

চিত্র 8: পরিদর্শন শুধু অভ্যন্তরীণ CA বিতরণের সাথে সেট হিসেবে কাজ করে।

8. বিচ্ছিন্নকরণ পদ্ধতি — অপরাধী চিহ্নিত করার পাঁচ ধাপ

«সংযোগ করতে পারি না» এই ক্রমে যান্ত্রিকভাবে তদন্ত করুন।

(2) PowerShell দিয়ে একসাথে সংগ্রহ করতে পারেন।

# (1) Per-user (WinINET) settings — note that this reads HKCU of the running account
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Machine (WinHTTP) settings
netsh winhttp show proxy

# (3) Environment variables
Get-ChildItem env: | Where-Object Name -match 'proxy'

কয়েকটি ব্যবহারিক টিপ।

• (1)-এর পুনরুৎপাদন পরীক্ষায় সচেতন থাকুন টুল কোন সেটিং পরিবার পড়ে। Windows-ইনবক্স curl.exe -x http://proxy:8080 দিয়ে প্রক্সি স্পষ্ট নির্দিষ্ট করতে পারে, আর TLS যাচাইয়ের জন্য সাধারণত OS সার্টিফিকেট স্টোর (Schannel) ব্যবহার করে। Windows PowerShell 5.1-এর Invoke-WebRequest .NET Framework পাশ (ডিফল্টে Internet Options) অনুসরণ করে; PowerShell 7 .NET পাশ (আগে এনভায়রনমেন্ট ভেরিয়েবল) অনুসরণ করে। «curl চলে কিন্তু অ্যাপ চলে না» নিজেই কনফিগারেশন পরিবারগুলোর অমিলের ইঙ্গিত।
• (3)-এর টার্গেট সার্ভিস হলে সার্ভিসের সমান অ্যাকাউন্টের অধীনে (1) ও (2) আবার পরীক্ষা করুন। অ্যাডমিনিস্ট্রেটরের নিজের সেশনে পরীক্ষা LocalSystem যা দেখে তার প্রমাণ নয়।
• (4)-এর ত্রুটি শ্রেণিবিন্যাসে 407-এর জন্য অধ্যায় ৬ (প্রমাণীকরণ) প্রথম প্রার্থী নিন, সার্টিফিকেট ত্রুটির জন্য অধ্যায় ৭ (TLS পরিদর্শন), আর টাইমআউটের জন্য «প্রক্সিতে পৌঁছায়নি» (পথ, নাম রেজোলিউশন, ফায়ারওয়াল)। কারণ প্রক্সি নয় Windows Firewall ইনবাউন্ড নিয়ম সেই প্যাটার্ন «Windows ফায়ারওয়াল ও ব্যবসায়িক অ্যাপ্লিকেশন» কভার করে।
• (5) পর্যন্ত গিয়েও প্রক্সি লগে চিহ্ন না থাকলে ট্রাফিক প্রক্সিতে কখনো পৌঁছায়নি। PAC-এর DIRECT সিদ্ধান্ত, বাইপাস তালিকা, বা পড়ে থাকা এনভায়রনমেন্ট ভেরিয়েবল সন্দেহ করুন, আর দরকার হলে প্যাকেট ক্যাপচার দিয়ে প্রকৃত গন্তব্য নিশ্চিত করুন («Windows-এ ব্যবহারিক প্যাকেট ক্যাপচার — pktmon, netsh trace ও Wireshark বেছে নেওয়া»)।

flowchart TB
    accTitle: প্রক্সি ব্যর্থতা বিচ্ছিন্ন করার পাঁচ ধাপ
    accDescr: একই অ্যাকাউন্টের অধীনে পুনরুৎপাদন করুন, সেটিংয়ের তিন পরিবার সংগ্রহ করুন, চলমান অ্যাকাউন্ট চিহ্নিত করুন, ত্রুটি শ্রেণিবদ্ধ করুন, তারপর প্রক্সি লগ পরীক্ষা করুন
    s1["curl দিয়ে পুনরুৎপাদন"] --> s2["তিন পরিবার সংগ্রহ"]
    s2 --> s3["অ্যাকাউন্ট চিহ্নিত করুন"]
    s3 --> s4["ত্রুটি শ্রেণিবদ্ধ করুন"]
    s4 --> s5["প্রক্সি লগ পরীক্ষা"]
    s4 -.-> e407["407: প্রমাণীকরণ"]
    s4 -.-> ecert["সার্টিফিকেট ত্রুটি: পরিদর্শন"]
    s4 -.-> eto["টাইমআউট: কখনো পৌঁছায়নি"]

চিত্র 9: পাঁচ ধাপ ক্রমে হাঁটুন। ত্রুটি শ্রেণি পরের অধ্যায় বেছে নেয়।

9. ডিজাইন সুপারিশ — অ্যাপ এমন করুন যাতে «প্রক্সি কনফিগার করা যায়»

তদন্ত পদ্ধতি উল্টালে তা অ্যাপ পাশের ডিজাইন নির্দেশিকা হয়ে যায়। কর্পোরেট প্রক্সি আছে এমন পরিবেশে পৌঁছে দিতে যাওয়া Windows অ্যাপের জন্য নিম্নলিখিত সুপারিশ।

1. অ্যাপ সেটিং থেকে প্রক্সি কনফিগারযোগ্য করুন। ডিফল্ট «OS সেটিং অনুসরণ»। বেশিরভাগ পরিবেশে ডিফল্টই যথেষ্ট; শুধু ব্যতিক্রমী পরিবেশে — PAC পড়া যায় না, সার্ভিস হিসেবে চলে, বিশেষ প্রক্সি কনফিগারেশন — সেটিং ফাইল থেকে প্রক্সি URL, বাইপাস তালিকা, ও «প্রক্সি ব্যবহার করবেন না» নির্দিষ্ট করা সম্ভব করুন। ধারা ৫.৩-এর HttpClientHandler.Proxy / UseProxy বাস্তবায়ন বিন্দু।¹⁴
2. লিখুন অভ্যন্তরীণ গন্তব্য (API, ডেটাবেস, লাইসেন্স সার্ভার ইত্যাদি) প্রক্সি ব্যতিক্রম হিসেবে কীভাবে আচরণিত। ডিপ্লয়মেন্ট পদ্ধতিতে লিখতে পারেন এমন রূপে রাখুন সেগুলো PAC DIRECT, বাইপাস তালিকা, নাকি NO_PROXY দিয়ে বাদ। NO_PROXY মিল নিয়ম (ওয়াইল্ডকার্ড নেই, অগ্রণী বিন্দুর অর্থ) ব্যাপক ভুল বোঝা যায়, তাই উদাহরণ লাগান।⁷
3. প্রক্সি দিয়ে যাওয়ার অনুমানে টাইমআউট ও পুনঃচেষ্টা ডিজাইন করুন। প্রক্সি ডাউন বা প্রমাণীকরণে আটকে থাকলে দীর্ঘ ডিফল্ট টাইমআউটে অপেক্ষা করা ইমপ্লিমেন্টেশন UI ও পরিচালনা দুটোই জমিয়ে দেয়। ছোট কানেক্ট টাইমআউট আলাদা করুন, আর পুনঃচেষ্টা আইডেমপোটেন্ট অনুরোধে সীমাবদ্ধ করুন (ডিজাইন বিস্তারিত «HttpClient-কে using ব্লকে মুড়ে ফেলবেন না»-এ)।
4. লগ করুন «কোন প্রক্সি ব্যবহৃত হয়েছিল»। অ্যাপ নিজেই ব্যর্থতা তদন্তের প্রথম প্রশ্নের উত্তর দিতে পারুক।

(4)-এর মতো লগ শুধু রেজোলিউশন ফল রেকর্ড করলেই আগে থেকে কার্যকর। বিষয় পথ সেই সেটিং (হ্যান্ডলার) থেকে নির্ণয় করা যা দিয়ে আপনি সত্যি ক্লায়েন্ট কনফিগার করেছেন। সরাসরি HttpClient.DefaultProxy লগ করলে হ্যান্ডলার স্পষ্ট Proxy দিলে বা UseProxy = false সেট করলে প্রকৃত পথের সাথে অমিল মান রেকর্ড হবে।

using System.Net.Http;

// handler is the same instance used to create the HttpClient
// UseProxy=false is always direct. An explicit specification wins; otherwise DefaultProxy is used
var effectiveProxy = handler.UseProxy
    ? handler.Proxy ?? HttpClient.DefaultProxy
    : null;
var target = new Uri("https://api.example.com/v1/orders");
var route = effectiveProxy is null || effectiveProxy.IsBypassed(target)
    ? "DIRECT"
    : effectiveProxy.GetProxy(target)?.ToString() ?? "DIRECT";
logger.LogInformation("HTTP send {Target} route {Route} account {User}",
    target, route, Environment.UserName);

স্টার্টআপে প্রধান গন্তব্যের জন্য একবার «পথ» ও «চলমান অ্যাকাউন্ট» রেকর্ড করলে অধ্যায় ৮-এর ধাপ (1) থেকে (3) শুধু লগ পড়ে শেষ হয়। যখন বলা হয় «ব্রাউজারে চলে, কিন্তু…», অ্যাপ পাশ থেকে বলতে পারা «আমি এই সেটিং ব্যবহার করেছি, আর এই পথ» প্রক্সি ঝামেলার বিরুদ্ধে শক্তিশালী অ্যাপের শর্ত।

flowchart TB
    accTitle: প্রক্সি কনফিগারযোগ্য করুন ও পথ লগ করুন
    accDescr: ডিফল্ট OS সেটিং অনুসরণ, অ্যাপ সেটিং থেকে স্পষ্ট প্রক্সি URL বা বাইপাস বা প্রক্সি-না অনুমতি দিন, আর সত্যি ব্যবহৃত পথ চলমান অ্যাকাউন্টের সাথে লগ করুন
    def["ডিফল্ট: OS সেটিং অনুসরণ"] --> exc{"ব্যতিক্রমী পরিবেশ?"}
    exc -->|"PAC অপঠিত / সার্ভিস / বিশেষ"| cfg["URL, বাইপাস, বা প্রক্সি ছাড়া সেট করুন"]
    exc -->|"সাধারণ ক্ষেত্র"| os["OS ডিফল্ট ব্যবহার করুন"]
    cfg --> log["পথ ও অ্যাকাউন্ট লগ করুন"]
    os --> log

চিত্র 10: যখন লাগে তখন কনফিগার করুন। সবসময় লগ করুন কোন পথ ব্যবহৃত হয়েছিল।

10. সারাংশ

• Windows প্রক্সি সেটিং তিন পরিবারে ভাগ — WinINET প্রতি-ব্যবহারকারী সেটিং, WinHTTP মেশিন সেটিং, ও এনভায়রনমেন্ট ভেরিয়েবল — আর কোনটি পড়া হয় অ্যাপ (তার HTTP স্ট্যাক) ও চলমান অ্যাকাউন্ট ঠিক করে।
• WinINET ইন্টারঅ্যাকটিভ অ্যাপের জন্য এবং সার্ভিসে ব্যবহার সমর্থিত নয়; সার্ভিস ব্যবহার WinHTTP-এর কাজ (netsh winhttp)। «হাতে চলে কিন্তু সার্ভিস হিসেবে নয়»-এ আগে চলমান অ্যাকাউন্টের পার্থক্য সন্দেহ করুন।
• netsh winhttp set proxy স্থির সেটিং এবং PAC, স্বয়ংক্রিয় শনাক্তকরণ বা প্রমাণীকরণ সামলায় না। PAC-চালিত নেটওয়ার্কে PAC পড়তে না পারা ক্লায়েন্ট কীভাবে আচরণ করবে ঠিক করতে হয়।
• PAC-এর FindProxyForURL URL অনুসারে প্রক্সি বা DIRECT ফেরায়। WPAD শুধু সেই নেটওয়ার্কে কাজ করে যেখানে DHCP/DNS ব্যবস্থা আছে।
• .NET Framework-এর ডিফল্ট চলমান অ্যাকাউন্টের Internet Options (defaultProxy দিয়ে ওভাররাইড); .NET (Core ও পরবর্তী) এনভায়রনমেন্ট ভেরিয়েবল তারপর ব্যবহারকারী প্রক্সি সেটিং। স্পষ্ট নির্দিষ্টকরণ (HttpClientHandler.Proxy) সবসময় সর্বোচ্চ অগ্রাধিকার।
• 407 প্রক্সি-প্রমাণীকরণ ত্রুটি; সার্ভিস অ্যাকাউন্টের অধীনে চলা অ্যাপে সাধারণ কারণ «ডিফল্ট ক্রেডেনশিয়াল» আলাদা ব্যক্তি হয়ে যায়।
• TLS-পরিদর্শন প্রক্সি অভ্যন্তরীণ CA সার্টিফিকেট বিতরণ ধরে, আর সার্টিফিকেট ত্রুটির সঠিক উত্তর যাচাই বন্ধ নয়, স্টোরে বিতরণ। পিন করা ট্রাফিক ছাড় চায়।
• «পুনরুৎপাদন → তিন পরিবারের সেটিং সংগ্রহ → চলমান অ্যাকাউন্ট চিহ্নিতকরণ → ত্রুটি শ্রেণিবিন্যাস → প্রক্সি লগ» ক্রমে যান্ত্রিকভাবে বিচ্ছিন্ন করুন। অ্যাপ পাশে «প্রক্সি কনফিগার করতে পারে, আর ব্যবহৃত পথ লগ করে» ডিজাইন সবচেয়ে ভালো প্রতিরোধ।

পরেরবার «শুধু ব্যবসায়িক অ্যাপ সংযোগ করতে পারে না» পরামর্শ এলে আগে এটি জিজ্ঞাসা করুন।

সেই অ্যাপ কার অ্যাকাউন্টের অধীনে চলছে, আর প্রক্সি সেটিংয়ের তিন পরিবারের কোনটি পড়ে?

সেই এক প্রশ্ন তদন্তের প্রবেশদ্বার অনেক বদলে দেয়।

সংশ্লিষ্ট নিবন্ধ

• HttpClient-কে using ব্লকে মুড়ে ফেলবেন না — C# ব্যবসায়িক অ্যাপে ব্যবহারিক HTTP যোগাযোগ (তৈরির প্যাটার্ন, টাইমআউট, পুনঃচেষ্টা)
• Windows-এ ব্যবহারিক প্যাকেট ক্যাপচার — pktmon, netsh trace ও Wireshark বেছে নেওয়া
• Windows ফায়ারওয়াল ও ব্যবসায়িক অ্যাপ্লিকেশন — ইনস্টলার থেকে ইনবাউন্ড নিয়ম নিবন্ধন
• Windows সার্ভিস কীভাবে বানান ও চালান ── Task Scheduler ও সার্ভিসের মধ্যে বেছে নেওয়া থেকে BackgroundService-কে Windows সার্ভিস বানানো
• চিত্রসহ NTLM ও Kerberos — প্রমাণীকরণ কেন NTLM-এ পড়ে
• ব্যবহারিক Windows সার্টিফিকেট স্টোর — ব্যবহারকারী না কম্পিউটার, কোনটি ব্যবহার করবেন?

সংশ্লিষ্ট পরামর্শ ক্ষেত্র

KomuraSoft LLC কর্পোরেট-প্রক্সি, প্রমাণীকরণ-প্রক্সি ও TLS-পরিদর্শন পরিবেশে Windows-অ্যাপ যোগাযোগ সমস্যার তদন্ত সামলায় — «ডেভেলপমেন্ট মেশিনে চলে কিন্তু গ্রাহক নেটওয়ার্কে যোগাযোগ করতে পারে না», «সার্ভিস বানানোর পর আর বাইরের API-তে পৌঁছায়নি» — এবং প্রক্সি পরিবেশ ধরে ব্যবসায়িক-অ্যাপ যোগাযোগ ডিজাইনের পরামর্শ (সেটিং আইটেম, টাইমআউট, লগ ডিজাইন)। পুনরুৎপাদন ধাপ ও লগ কীভাবে সংগ্রহ করবেন সাজিয়ে শুরু করা ঠিক।

• Windows অ্যাপ ডেভেলপমেন্ট
• বাগ ও কারণ তদন্ত
• প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

ব্রাউজার সংযোগ করতে পারে, কিন্তু শুধু ব্যবসায়িক অ্যাপ কর্পোরেট প্রক্সি পেরোতে পারে না। কেন?

ব্রাউজার WinINET-এর প্রতি-ব্যবহারকারী প্রক্সি সেটিং পড়ে, কিন্তু ব্যবসায়িক অ্যাপ একই সেটিং পড়ে না। Windows সার্ভিস হিসেবে, বা অন্য অ্যাকাউন্টের অধীনে চলা অ্যাপ সেই অ্যাকাউন্ট থেকে দৃশ্যমান সেটিং, WinHTTP-এর মেশিন সেটিং, বা এনভায়রনমেন্ট ভেরিয়েবল দেখে। আগে চলমান অ্যাকাউন্ট চিহ্নিত করুন, তারপর সেই অ্যাকাউন্ট থেকে দৃশ্যমান প্রক্সি সেটিং netsh winhttp show proxy ও ব্যবহারকারী সেটিং দুটোতেই পরীক্ষা করুন। একই মেশিনে একই অ্যাকাউন্টে curl.exe ইত্যাদি দিয়ে পুনরুৎপাদন করতে পারলে অ্যাপ-নির্দিষ্ট সমস্যা নয়, কনফিগারেশন পরিবারগুলোর অমিল ধরুন।

netsh winhttp set proxy সেট করেছি, কিন্তু অ্যাপের ট্রাফিক বদলায়নি। কেন?

netsh winhttp যা সেট করে তা WinHTTP-এর মেশিন ডিফল্ট। এটি WinINET পড়া ব্রাউজার বা ইন্টারঅ্যাকটিভ অ্যাপ, বা এনভায়রনমেন্ট ভেরিয়েবল অগ্রাধিকার দেওয়া .NET (Core ও পরবর্তী) HttpClient-কে প্রভাবিত করে না। netsh winhttp set proxy স্থির সেটিংও; PAC স্বয়ংক্রিয় কনফিগারেশন, স্বয়ংক্রিয় শনাক্তকরণ বা প্রক্সি প্রমাণীকরণ সামলায় না। আগে নিশ্চিত করুন টার্গেট অ্যাপ কোন HTTP স্ট্যাক ব্যবহার করে এবং কোন কনফিগারেশন পরিবার থেকে প্রক্সি রেজোলিভ করে।

.NET অ্যাপ কোন প্রক্সি সেটিং পড়ে?

.NET Framework ডিফল্টে চলমান অ্যাকাউন্টের Internet Options (WinINET-সমতুল্য) সেটিং ব্যবহার করে, এবং app.config-এর system.net/defaultProxy এলিমেন্ট দিয়ে ওভাররাইড করা যায়। .NET (Core ও পরবর্তী)-এ HttpClient আগে HTTP_PROXY, HTTPS_PROXY ও NO_PROXY-এর মতো এনভায়রনমেন্ট ভেরিয়েবল পড়ে, আর সংজ্ঞায়িত না থাকলে Windows ব্যবহারকারী প্রক্সি সেটিংয়ে পড়ে। দুই ক্ষেত্রেই স্পষ্ট HttpClientHandler.Proxy অগ্রাধিকার পায়। ডিফল্ট রেজোলিউশন ক্রম Framework ও Core ও পরবর্তীর মধ্যে আলাদা, তাই মাইগ্রেট করলে প্রক্সি আচরণ আবার পরীক্ষা করুন।

407 Proxy Authentication Required ফিরলে কী পরীক্ষা করব?

407 চিহ্ন যে প্রক্সি নিজেই প্রমাণীকরণ চাইছে; এটি গন্তব্য-সার্ভার প্রমাণীকরণ ত্রুটি (401) থেকে আলাদা। আগে Proxy-Authenticate হেডার থেকে প্রক্সি কোন স্কিম চাইছে (Negotiate, NTLM, Basic) নিশ্চিত করুন, এবং .NET-এ HttpClientHandler.DefaultProxyCredentials বা WebProxy.UseDefaultCredentials দিয়ে ক্রেডেনশিয়াল দিন। সার্ভিস অ্যাকাউন্টের অধীনে চলা অ্যাপে «ডিফল্ট ক্রেডেনশিয়াল» সেই সার্ভিস অ্যাকাউন্টের হয়ে যায়, তাই সাধারণ ঘটনা ইন্টারঅ্যাকটিভ ব্যবহারকারীর জন্য চলে তারপর সার্ভিস বানালেই 407। প্রক্সি-সাইড লগেও দেখুন সে কার হিসেবে প্রমাণীকৃত হয়েছে।

TLS-পরিদর্শন প্রক্সি সার্টিফিকেট ত্রুটি দেয়। সার্টিফিকেট যাচাই বন্ধ করতে পারি?

বন্ধ করা সুপারিশ নয়। TLS-পরিদর্শন প্রক্সি ট্রাফিক ডিক্রিপ্ট করে তারপর ক্লায়েন্টকে নিজের CA দিয়ে পুনঃস্বাক্ষরিত সার্টিফিকেট দেখায়, তাই সেই CA সার্টিফিকেট বিশ্বস্ত রুটে না থাকলে যাচাই ব্যর্থ হয়। সঠিক সমাধান অভ্যন্তরীণ CA সার্টিফিকেট Windows সার্টিফিকেট স্টোরে (সাধারণত লোকাল কম্পিউটারের Trusted Root Certification Authorities) বিতরণ করা। কোডে যাচাই বন্ধ মানে বাইরের নেটওয়ার্কে অ্যাপ ব্যবহার হলে ম্যান-ইন-দ্য-মিডল আক্রমণ ধরা যায় না, আর দুর্বলতা থেকে যায়।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।