প্রতি ব্রাউজার প্রোফাইলে প্রক্সি: DNS, প্রমাণীকরণ ও ব্যর্থতার ধরন

এই গাইডে Chromium-এর নথিবদ্ধ নেটওয়ার্ক আচরণকে ভিত্তি ধরা হয়েছে। অন্য ব্রাউজার ও পণ্য ভিন্ন সিদ্ধান্ত নিতে পারে, এবং ব্রাউজার ম্যানেজার Chromium-এর চারপাশে স্থানীয় নেটওয়ার্ক ব্রোকার যোগ করতে পারে। আপনি যে নির্দিষ্ট বিল্ড চালান, তার আচরণ যাচাই করুন।

চারটি স্বাধীন প্রশ্ন দিয়ে শুরু করুন

একটি প্রক্সি নথিতে সাধারণত স্কিম, এন্ডপয়েন্ট, পোর্ট এবং কখনও প্রমাণীকরণের রেফারেন্স থাকে। ওই নথি থেকে চারটি আলাদা নীতির প্রশ্ন আসে:

1. পরিধি: কোন ব্রাউজারের অনুরোধ ও কোন প্রোটোকল এই প্রক্সির পথে যাবে?
2. নাম রেজল্যুশন: গন্তব্যের হোস্টনেম ডিভাইস রেজলভ করবে, নাকি প্রক্সি?
3. প্রমাণীকরণ: কোন ক্লায়েন্ট ও প্রক্সি স্কিম একসঙ্গে কাজ করে, এবং পরিচয়প্রমাণ কোথায় রাখা হয়?
4. ব্যর্থতা: সংযোগের ত্রুটি কি অনুরোধ থামাবে, অন্য প্রক্সি চেষ্টা করবে, নাকি সরাসরি পথে ফিরে যাবে?

এগুলোকে একটিমাত্র “প্রক্সি চালু” সুইচ ভাবলেই বেশিরভাগ অপ্রত্যাশিত সমস্যা হয়। Chromium প্রক্সি নির্বাচনকে URL-স্তরের রেজল্যুশন হিসেবে নথিবদ্ধ করেছে: গন্তব্য রেজলভ হওয়ার আগেই URL থেকে প্রক্সি-পছন্দের একটি ক্রমতালিকা তৈরি হয়। বাইপাস ও বিকল্প নিয়মও সেই সিদ্ধান্তের অংশ।

প্রতি প্রোফাইলের প্রক্সি কী কভার করে

Google-এর ProxySettings নীতি Chrome প্রোফাইল স্তরে প্রয়োগ হয়। এতে সরাসরি, সিস্টেম, স্বয়ংক্রিয়ভাবে শনাক্ত, নির্দিষ্ট সার্ভার বা PAC-স্ক্রিপ্টের ধরন বেছে নেওয়া যায়; পাশাপাশি স্পষ্ট বাইপাস ও PAC-আবশ্যিক ক্ষেত্র থাকে।

এই সীমা VPN বা অপারেটিং সিস্টেমের নেটওয়ার্ক নেমস্পেসের চেয়ে সংকীর্ণ। এটি ব্রাউজারের নেটওয়ার্ক প্রসঙ্গ যে অনুরোধ সামলায়, তা নিয়ন্ত্রণ করে। স্বয়ংক্রিয়ভাবে নিচের বিষয়গুলো নিয়ন্ত্রণ করে না:

• ডেস্কটপ ম্যানেজারের নিজের API কল;
• প্রক্রিয়ার বাইরের অ্যাপ্লিকেশন বা ব্রাউজার আপডেটার;
• অপারেটিং সিস্টেমের DNS ও সংযোগ যাচাই;
• ডাউনলোড করা ফাইল থেকে চালু হওয়া অন্য অ্যাপ্লিকেশন;
• এক্সটেনশনের আলাদা স্থানীয় সহায়ক;
• অন্তর্নিহিত লুপব্যাক বাইপাসে পাওয়া স্থানীয় পরিষেবা; অথবা
• নির্বাচিত প্রক্সি-পথ যে প্রোটোকল বহন করতে পারে না, সেই ট্র্যাফিক।

এই উপাদানগুলোর কিছু অংশের নিজস্ব প্রক্সি-সহায়তা থাকতে পারে। সেই সহায়তা আলাদাভাবে নির্দিষ্ট ও পরীক্ষা করতে হবে। “প্রোফাইলের ট্র্যাফিক এই প্রক্সি ব্যবহার করে”—এমন ব্রাউজার-পণ্য বক্তব্যে পুরো ডিভাইসের রাউটিং বোঝানো উচিত নয়; কোন প্রক্রিয়া ও প্রোটোকল অন্তর্ভুক্ত, তা বলতে হবে।

একটি HTTPS অনুরোধ অনুসরণ করুন

স্বাভাবিক HTTPS নেভিগেশনের পথে কয়েকটি ধাপ থাকে।

১. পথ বেছে নিন

ব্রাউজার নির্দিষ্ট নিয়ম, প্রক্সির স্বয়ংক্রিয় কনফিগারেশন স্ক্রিপ্ট বা সিস্টেম সেটিং মূল্যায়ন করে। বাইপাসের সঙ্গে মিললে সরাসরি সংযোগ বেছে নেওয়া যায়। প্রক্সি-তালিকায় প্রধান প্রক্সির পরে বিকল্প থাকতে পারে; সরাসরি বিকল্প অনুমোদিত হলে DIRECT-ও থাকতে পারে।

Chromium localhost ও লিংক-স্থানীয় গন্তব্যের জন্য অন্তর্নিহিত বাইপাসও প্রয়োগ করে। এটি বাইরে থেকে নিয়ন্ত্রিত প্রক্সি সেটিং থেকে স্থানীয় origin-কে রক্ষা করে, কিন্তু “সব ট্র্যাফিক” বললে এই সীমাটি উল্লেখ করতে হয়।

২. প্রক্সিতে পৌঁছে রেজলভ করুন

প্রক্সির এন্ডপয়েন্ট যদি হোস্টনেম হয়, ডিভাইসকে সেই এন্ডপয়েন্ট রেজলভ ও সংযোগ করার উপায় লাগবে। দূরবর্তী গন্তব্যের DNS জানা থাকলেই এই প্রাথমিক অনুসন্ধান বাদ যায় না। এই ব্যর্থতা প্রক্সিতে পৌঁছনো গেলেও গন্তব্য রেজলভ করতে না পারার ব্যর্থতা থেকে আলাদা।

৩. প্রক্সিতে প্রমাণীকরণ করুন

পরিচয়প্রমাণ চাওয়া HTTP প্রক্সি সাধারণত চ্যালেঞ্জসহ 407 Proxy Authentication Required ফেরত দেয়। RFC 9110 এই বিনিময় এবং Proxy-Authenticate ও Proxy-Authorization ক্ষেত্র সংজ্ঞায়িত করেছে।

Chromium ম্যানুয়াল প্রক্সি সেটিংয়ে বসানো username ও পাসওয়ার্ড ব্যবহার করে না। তার প্রক্সি নথি বলছে, প্রমাণীকরণ ব্রাউজারের সাধারণ পরিচয়প্রমাণের প্রবাহ অনুসরণ করে। তাই প্রোফাইল ম্যানেজারের সমর্থিত চ্যালেঞ্জের জন্য স্পষ্ট সমন্বয় দরকার; যেকোনো user:password@host স্ট্রিং কাজ করবে—এমন প্রতিশ্রুতি যথেষ্ট নয়।

৪. গন্তব্যের সংযোগ তৈরি করুন

HTTP প্রক্সিতে Chromium গন্তব্যের নাম রেজল্যুশন প্রক্সির কাছে ছেড়ে দেয়। HTTPS গন্তব্য হলে ব্রাউজার প্রক্সিকে CONNECT টানেল তৈরি করতে বলে, তারপর সেই টানেলের মাধ্যমে গন্তব্যের সঙ্গে প্রান্ত-থেকে-প্রান্ত TLS স্থাপন করে।

প্রক্সি গন্তব্যের হোস্টনেম ও সংযোগের মেটাডেটা জানতে পারে। ক্লায়েন্ট-থেকে-প্রক্সি ধাপটি সাধারণ HTTP হলে ওই ধাপে CONNECT অনুরোধ ও হোস্টনেম সুরক্ষিত থাকে না। HTTPS প্রক্সি ব্রাউজার ও প্রক্সির মধ্যে TLS যোগ করে, ফলে মাঝের পর্যবেক্ষকদের কাছ থেকে মেটাডেটা সুরক্ষিত হয়। কিন্তু প্রক্সি নিজে অনুরোধ করা গন্তব্য দেখতে পারবে না—এমন নয়।

টানেলের ভেতরের HTTPS পৃষ্ঠার বিষয়বস্তু প্রক্সি সাধারণত পড়তে পারে না। TLS interception আলাদা আস্থার মডেল, যেখানে ক্লায়েন্ট এমন সার্টিফিকেট কর্তৃপক্ষকে বিশ্বাস করে যা মধ্যস্থতাকারীকে TLS খুলে আবার তৈরি করতে দেয়। সাধারণ ফরওয়ার্ডিংয়ের সঙ্গে এটিকে কখনও চুপিসারে এক করে দেখবেন না।

প্রক্সি স্কিম অনুযায়ী DNS-এর মালিকানা বদলায়

Chromium-এর নথিবদ্ধ আচরণ প্রক্সির ধরন অনুযায়ী আলাদা:

নির্বাচিত পথ	Chromium-এ গন্তব্যের নাম রেজল্যুশন	গুরুত্বপূর্ণ সীমা
সরাসরি বা বাইপাস	ডিভাইস বা ব্রাউজারের রেজলভার	গন্তব্যের ট্র্যাফিক প্রোফাইলের প্রক্সি ছাড়াই বেরিয়ে যায়
HTTP প্রক্সি	প্রক্সির দিক	সাধারণ HTTP-তে ক্লায়েন্ট-থেকে-প্রক্সি পরিবহন HTTP অনুরোধ প্রকাশ করে; HTTPS-এ CONNECT ব্যবহৃত হয়
HTTPS প্রক্সি	প্রক্সির দিক	ক্লায়েন্টকে প্রক্সির TLS সার্টিফিকেট যাচাই করতে হয়
SOCKS4 প্রক্সি	ক্লায়েন্টের দিক	শুধু IPv4 গন্তব্য; Chromium SOCKS4a বিকল্প বাস্তবায়ন করে না
SOCKS5 প্রক্সি	প্রক্সির দিক	TCP URL অনুরোধে ব্যবহৃত হয়; Chromium SOCKS5 প্রমাণীকরণ সমর্থন করে না

RFC 1928 SOCKS5 অনুরোধে ডোমেন নাম বহনের অনুমতি দেয় এবং একাধিক প্রমাণীকরণ-পদ্ধতির শনাক্তকারী নির্ধারণ করে। প্রোটোকলের সক্ষমতা মানেই ক্লায়েন্টের বাস্তবায়ন নয়। Chromium বর্তমানে গন্তব্যের নাম SOCKS5 প্রক্সিতে পাঠায়, কিন্তু জানায় যে তার বিল্ট-ইন SOCKS5 ক্লায়েন্ট কোনো প্রক্সি-প্রমাণীকরণ পদ্ধতি সমর্থন করে না। তাই username-পাসওয়ার্ডসহ SOCKS5 দেওয়া পরিষেবা-দাতার জন্য সমর্থিত মধ্যস্থতাকারী বা অন্য প্রক্সি স্কিম লাগতে পারে। রেকর্ড গ্রহণের আগে ব্রাউজারের বাস্তবায়ন নিশ্চিত করুন।

DNS-over-HTTPS আরও একটি স্তর যোগ করে। Chrome-এর DnsOverHttpsMode নীতি automatic ধরনকে আলাদা করে, যা অনিরাপদ DNS-এ বিকল্প নিতে পারে, এবং secure ধরনকে আলাদা করে, যা নিরাপদ DNS ব্যর্থ হলে রেজল্যুশন ব্যর্থ করে। একই নীতি ব্রাউজার-স্তরের, আর ProxySettings প্রোফাইল-স্তরের। এই অমিল একটি সতর্কতা: কোনো সেটিংয়ে “প্রোফাইল” লেখা থাকলেই সব DNS নিয়ন্ত্রণের একই পরিধি বোঝায় না।

প্রতিটি প্রোফাইল আলাদা ব্রাউজার প্রক্রিয়ায় চালানো পণ্যের কার্যকর সীমা আরও সংকীর্ণ করতে পারে, কিন্তু এটি বাস্তবায়নের পছন্দ। পরীক্ষা করুন। প্রমাণে আলাদা করে দেখানো উচিত:

• প্রক্সি এন্ডপয়েন্টের রেজল্যুশন;
• অনুরোধ করা গন্তব্যের রেজল্যুশন;
• সরাসরি বা বাইপাস অনুরোধে ব্যবহৃত DNS;
• নিরাপদ DNS-এর প্রাথমিক অনুসন্ধান ও বিকল্প পথ; এবং
• প্রোফাইলের ব্রাউজার নেটওয়ার্ক প্রসঙ্গের বাইরের উপাদানের করা DNS।

প্রমাণীকরণের সামঞ্জস্য ও গোপন তথ্যের ব্যবস্থাপনা—দুই সমস্যাই

Chromium HTTP প্রক্সির জন্য Basic, Digest, Negotiate ও NTLM নথিবদ্ধ করেছে। HTTPS প্রক্সি সুরক্ষিত ক্লায়েন্ট-থেকে-প্রক্সি চ্যানেল যোগ করে এবং ক্লায়েন্ট সার্টিফিকেটও সমর্থন করতে পারে। SOCKS4 ও SOCKS5 প্রমাণীকরণ Chromium-এর বিল্ট-ইন প্রক্সি ক্লায়েন্টে বাস্তবায়িত নয়, যদিও SOCKS5 স্পেসিফিকেশনে প্রমাণীকরণ পদ্ধতি আছে।

সামঞ্জস্যপূর্ণ স্কিমও ভুল পরিবহনে অনিরাপদ হতে পারে। RFC 7617 ব্যাখ্যা করে, Basic পরিচয়প্রমাণ শুধু Base64-এ এনকোড করা এবং TLS-এর মতো সুরক্ষিত চ্যানেল দরকার। সাধারণ HTTP প্রক্সিতে Basic প্রমাণীকরণ ব্যবহার করলে ওই ধাপ দেখতে পারে এমন যে কেউ প্রক্সির পাসওয়ার্ড দেখতে পারে।

প্রোফাইল ম্যানেজারে নিচের ডেটাগুলো আলাদা রাখা উচিত:

• গোপন নয় এমন এন্ডপয়েন্ট মেটাডেটা, যেমন স্কিম, host, port ও পরিষেবা-দাতার label;
• জীবনচক্র বা নেটওয়ার্ক পরিষেবা যে গোপন তথ্যের রেফারেন্স ব্যবহার করে;
• সুরক্ষিত সংরক্ষণে পরিচয়প্রমাণের মান;
• ইন্টারফেস ও অডিট ট্রেলের জন্য গোপন অংশ বাদ দেওয়া সংযোগের অবস্থা; এবং
• নিয়ন্ত্রিত সহায়তা-প্রবাহ ছাড়া অনুপলভ্য ডায়াগনস্টিক বিবরণ।

সাধারণ স্ক্রিন, লগ, API, export বা automation output-এ প্রক্সির পাসওয়ার্ড দরকার হয় না। কর্মীর সাধারণত জানা দরকার প্রমাণীকরণ ব্যর্থ হয়েছে কি না, কোন স্কিম চ্যালেঞ্জ দিয়েছে, কোন এন্ডপয়েন্ট জড়িত এবং বিকল্প পথ নেওয়া হয়েছিল কি না।

ব্যর্থতার ধরন ও তার চেহারা

ব্যর্থতা	সম্ভাব্য লক্ষণ	যে সীমা যাচাই করতে হবে
ভুল প্রক্সি স্কিম	TLS বা প্রোটোকল handshake ব্যর্থ	HTTPS এন্ডপয়েন্টকে HTTP বা উল্টো করে লেখা হয়েছে কি?
প্রক্সির হোস্টনেম রেজলভ হয় না	প্রক্সিতে পৌঁছনোর আগেই সংযোগ ব্যর্থ	প্রাথমিক অনুসন্ধান কোন রেজলভার করেছে?
প্রক্সি পোর্টে পৌঁছনো যায় না	Timeout বা সংযোগ প্রত্যাখ্যান	তালিকায় পরের প্রক্সি বা DIRECT আছে কি?
প্রমাণীকরণ চ্যালেঞ্জ সমর্থিত নয়	বারবার 407 বা সাইন-ইন অনুরোধ	ব্রাউজার চ্যালেঞ্জ করা স্কিম বাস্তবায়ন করে কি?
পরিচয়প্রমাণ ভুল বা মেয়াদোত্তীর্ণ	পরিচয়প্রমাণ পাঠানোর পর 407	গোপন তথ্যের রেফারেন্স রেজলভ হয়েছে এবং output থেকে গোপন অংশ বাদ পড়েছে কি?
HTTPS প্রক্সি সার্টিফিকেট ব্যর্থতা	প্রক্সির সুরক্ষিত সংযোগ প্রত্যাখ্যাত	সার্টিফিকেট যাচাই অক্ষুণ্ণ আছে কি?
প্রক্সি গন্তব্য রেজলভ করতে পারে না	প্রক্সি-নির্দিষ্ট হোস্ট বা টানেল ব্যর্থতা	ক্লায়েন্ট গন্তব্যে সরাসরি আবার চেষ্টা করছে না তো?
CONNECT প্রত্যাখ্যাত	ওই গন্তব্যের HTTPS নেভিগেশন ব্যর্থ	প্রত্যাখ্যানকে নীতি হিসেবে দেখা হচ্ছে, বাইপাস করার অনুমতি হিসেবে নয় তো?
PAC ফাইল অনুপলভ্য	প্রক্সি রেজল্যুশন থেমে যায় বা পথ বদলে যায়	PAC আবশ্যিক কি, নাকি Chromium নীরবে DIRECT ব্যবহার করতে পারে?
বাইপাসের ধরন অতিরিক্ত বিস্তৃত	নির্বাচিত সাইট সরাসরি সংযোগ করে	নির্দিষ্ট host, subdomain, port ও অন্তর্নিহিত নিয়ম বোঝা হয়েছে কি?
WebRTC অন্য ইন্টারফেস ব্যবহার করে	মিডিয়া-পথ পৃষ্ঠার ট্র্যাফিক থেকে আলাদা	প্রোফাইলের জন্য প্রক্সি-বহির্ভূত UDP নিষ্ক্রিয় কি?
পরিবর্তনের পর পুরনো সংযোগ থাকে	পুরনো পথ কিছু সময় সক্রিয় থাকে	সংযোগ ধীরে বন্ধ করা বা প্রোফাইল পুনরায় চালু হয় কি?
ডায়াগনস্টিক ক্যাপচার অতিরিক্ত বিস্তারিত	URL, হোস্টনেম বা গোপন তথ্য সহায়তা-ফাইলে ঢোকে	কোন redaction ধরন ও সংরক্ষণ-নিয়ম প্রযোজ্য?

Chromium-এর বিকল্প পথের অবস্থা স্থির নয়। সংযোগ-স্তরের ব্যর্থতা হওয়া প্রক্সিকে কিছু সময়ের জন্য অকার্যকর ধরে তালিকার অন্য এন্ট্রির পরে সরিয়ে রাখা হতে পারে। তালিকায় DIRECT থাকলে পরের অনুরোধ প্রক্সি ছাড়া বেরিয়ে যেতে পারে। CONNECT প্রত্যাখ্যান আলাদাভাবে সামলানো হয়, কারণ এটি অনুপলভ্য প্রক্সি নয়; ইচ্ছাকৃত গন্তব্য-নীতিও হতে পারে।

PAC ব্যর্থতার দিকে বিশেষ নজর দিন। Chromium নথিবদ্ধ করেছে, PAC ফাইল অনুপলভ্য হলে PAC আবশ্যিক হিসেবে চিহ্নিত না থাকলে সরাসরি রেজল্যুশনে নীরব বিকল্প নেওয়া হতে পারে। সরাসরি বিকল্প ঠেকাতেই Chrome-এর ProxySettings নীতিতে ProxyPacMandatory আছে।

WebRTC ও UDP-র জন্য আলাদা সিদ্ধান্ত দরকার

একটি পৃষ্ঠা এমন WebRTC পথ ব্যবহার করতে পারে যা সাধারণ HTTP ও HTTPS URL অনুরোধের সমতুল্য নয়। Chrome-এর default WebRtcIPHandling নীতি সব উপলভ্য ইন্টারফেস ব্যবহার করতে পারে। disable_non_proxied_udp ধরন WebRTC-কে public interface-এ TCP-তে সীমিত করে, যদি কনফিগার করা প্রক্সি UDP সমর্থন না করে।

এই নীতি প্রোফাইল-স্তরের হিসেবে নথিবদ্ধ, তাই প্রোফাইলের প্রক্সির জন্য প্রাসঙ্গিক; তবু এটি আলাদা নিয়ন্ত্রণ। এতে মিডিয়ার কর্মক্ষমতা কমতে বা সরাসরি UDP দরকার এমন কাজের ধাপ ভেঙে যেতে পারে। সুবিধা-অসুবিধা স্পষ্টভাবে বেছে নিয়ে পরীক্ষা করুন। শুধু পৃষ্ঠা লোড সফল হয়েছে বলে পূর্ণ প্রক্সি-আবদ্ধতা দাবি করবেন না।

ব্যর্থ হলে কাজ বন্ধ থাকবে, নাকি সরাসরি পথ চলবে—সিদ্ধান্ত নিন

উপলভ্যতা গুরুত্বপূর্ণ সাধারণ ব্রাউজিং প্রোফাইলে সরাসরি বিকল্প বৈধ হতে পারে। কিন্তু অনুমোদন, গোপনীয়তা বা আঞ্চলিক পরীক্ষার বৈধতা যদি নির্দিষ্ট বহির্গমন-পথের ওপর নির্ভর করে, সেখানে এটি অনিরাপদ।

ভালো প্রোফাইল নীতিতে প্রত্যাশিত আচরণ লেখা থাকে:

• প্রয়োজনীয় প্রক্সি: নির্বাচিত পথ ব্যবহার করা না গেলে প্রভাবিত নেটওয়ার্ক অনুরোধ থামান।
• অনুমোদিত প্রক্সি-সমষ্টি: একই নীতিতে নাম দেওয়া বিকল্পই চেষ্টা করুন।
• সরাসরি বিকল্প অনুমোদিত: পথ বদলেছে তা দেখান এবং গোপন মান ছাড়া ঘটনাটি নথিবদ্ধ করুন।
• স্পষ্ট বাইপাস: কোন গন্তব্য-শ্রেণি কেন সরাসরি প্রবেশাধিকার চায়, তা লিখুন।

চালুর আগে ও ব্যর্থতার পরে ইন্টারফেসে পথের অবস্থা দেখা উচিত। প্রক্সি থেকে সরাসরি পথে নীরবে বদলে গেলে নেটওয়ার্ক ত্রুটি অখণ্ডতার ত্রুটি হয়ে যায়: ভুল পথ ব্যবহার করেও কাজের ধাপ সফল মনে হতে পারে।

নিরাপদ যাচাইয়ের তালিকা

নিজের মালিকানাধীন বা পরীক্ষা করার অনুমতি থাকা এন্ডপয়েন্ট ও DNS জোন ব্যবহার করুন। পরীক্ষা চালানোর আগে প্রত্যাশিত ফল লিখে রাখুন।

1. ঘোষিত প্রক্সি স্কিম প্রকৃত এন্ডপয়েন্ট পরিবহনের সঙ্গে মিলিয়ে দেখুন।
2. সফল HTTP, HTTPS, WebSocket ও প্রয়োজনীয় WebRTC আচরণ নিশ্চিত করুন।
3. নিয়ন্ত্রিত গন্তব্যে বহির্গমন ঠিকানা দেখুন।
4. কোন রেজলভার গন্তব্যের অনুসন্ধান পায় এবং কোন রেজলভার প্রক্সি হোস্টনেমের প্রাথমিক অনুসন্ধান করে, তা দেখুন।
5. পরীক্ষার পরিচয়প্রমাণের মেয়াদ শেষ করে নিশ্চিত করুন, ইন্টারফেস, লগ বা automation output-এ কাঁচা মান নেই।
6. প্রক্সিকে অনুপলভ্য করে কনফিগার করা প্রবেশাধিকার-রোধ বা বিকল্প ফল নিশ্চিত করুন।
7. একটি নিয়ন্ত্রিত CONNECT গন্তব্য প্রত্যাখ্যান করে নিশ্চিত করুন, নীতির প্রত্যাখ্যান সরাসরি প্রবেশাধিকারে বদলে যায় না।
8. PAC অনুপলভ্য করে আবশ্যিক আচরণ নিশ্চিত করুন।
9. কাজের প্রয়োজন অনুযায়ী নির্দিষ্ট host, subdomain, local, link-local, IPv4 ও IPv6 বাইপাসের ঘটনা চালান।
10. সংযোগ সক্রিয় থাকা অবস্থায় প্রক্সি বদলে নতুন পথ কখন কার্যকর হয়, তা যাচাই করুন।
11. পরীক্ষার জন্য যতটুকু ডায়াগনস্টিক বিবরণ দরকার ততটুকুই ক্যাপচার করুন, তারপর সংরক্ষণ ও মুছে ফেলার নিয়ম যাচাই করুন।

Chromium-এর NetLog নির্দেশনা নেটওয়ার্ক লগিংকে গোপনীয়তা ও নিরাপত্তার উদ্বেগ হিসেবে দেখে। গোপন অংশ বাদ দেওয়ার ধরন সংবেদনশীল ক্ষেত্র বাদ দিতে পারে, আর বিস্তারিত ধরনে কুকি বা প্রমাণীকরণ হেডার থাকতে পারে। সহায়তা-ফাইলকে ফাইলের নাম দেখে নয়, প্রকৃত ক্যাপচারের ধরন অনুযায়ী পরিচালনা করতে হবে।