যদি কোনো লোকাল ওয়েবসাইট বা ডেভেলপমেন্ট সার্ভার 127.0.0.1-এ কাজ করে কিন্তু localhost-এ ব্যর্থ হয়, অথবা একটি অ্যাড্রেস ফ্যামিলিতে কাজ করে কিন্তু অন্যটিতে না করে, তবে সার্ভারের লিসেনিং অ্যাড্রেস পরীক্ষা করুন এবং প্রতিটি পাথ আলাদাভাবে টেস্ট করুন। ম্যাক-এ, 127.0.0.1 হলো IPv4 লুপব্যাক অ্যাড্রেস এবং ::1 হলো IPv6 লুপব্যাক অ্যাড্রেস; উভয়ই আপনার নিজের কম্পিউটারকে নির্দেশ করে। একটিতে সফল টেস্ট প্রমাণ করে না যে সার্ভিসটি অন্যটিতে শুনছে।

১. সার্ভিসটি শুনছে কিনা তা পরীক্ষা করুন

আপনার অ্যাপ্লিকেশনের যে পোর্টে সার্ভ করার কথা সেটি ব্যবহার করুন। নিচের উদাহরণগুলোতে পোর্ট 8000 ব্যবহার করা হয়েছে; এটিকে প্রকৃত পোর্ট দিয়ে প্রতিস্থাপন করুন।

lsof -nP -iTCP:8000 -sTCP:LISTEN

lsof নেটওয়ার্ক সকেটসহ ওপেন ফাইলগুলোর তালিকা তৈরি করে। অপশনগুলো ফলাফলকে সেই পোর্টের TCP লিসেনারে সীমাবদ্ধ করে এবং নাম সমাধান (resolve) করা এড়িয়ে চলে। যদি কোনো আউটপুট না থাকে, তবে সার্ভিসটি চালু নাও থাকতে পারে, অন্য কোনো পোর্ট ব্যবহার করতে পারে, অথবা কোনো TCP লিসেনার ওপেন নাও করতে পারে। macOS নেটওয়ার্ক সেটিংস পরিবর্তন করার আগে অ্যাপ্লিকেশনের স্টার্টআপ আউটপুট এবং কনফিগার করা পোর্ট পরীক্ষা করে দেখুন। (lsof ম্যানুয়াল)

NAME কলামে থাকা অ্যাড্রেসটি দেখুন। 127.0.0.1:8000-এ দেখানো লিসেনারটি IPv4 লুপব্যাকের সাথে আবদ্ধ (bound); আর [::1]:8000-এ দেখানো লিসেনারটি IPv6 লুপব্যাকের সাথে আবদ্ধ। সার্ভার এবং অপারেটিং সিস্টেমের ওপর নির্ভর করে ওয়াইল্ডকার্ড অ্যাড্রেস লুপব্যাকের চেয়ে বেশি কিছুতে লিসেনিং নির্দেশ করতে পারে। মূল ডায়াগনস্টিক হলো সার্ভারের প্রকৃত বাইন্ড অ্যাড্রেসটিতে আপনি যে অ্যাড্রেস ফ্যামিলি টেস্ট করছেন তা অন্তর্ভুক্ত কিনা। এই ব্যাখ্যাটি lsof দ্বারা রিপোর্ট করা সকেট অ্যাড্রেস থেকে আসে; অ্যাপ্লিকেশনের কনফিগারেশন নির্ধারণ করে সার্ভারটি কোন অ্যাড্রেস ওপেন করে।

২. IPv4 এবং IPv6 সরাসরি টেস্ট করুন

প্রতিটি লুপব্যাক অ্যাড্রেসের মাধ্যমে একই পোর্ট এবং পাথে একটি রিকোয়েস্ট পাঠান। ব্রাউজারের অ্যাড্রেস নির্বাচনের ওপর নির্ভর না করে curl আপনাকে HTTP কানেকশন টেস্ট করতে দেয়।

curl -v --connect-timeout 3 http://127.0.0.1:8000/
curl -g -v --connect-timeout 3 'http://[::1]:8000/'

URL-এ IPv6 লিটারালের চারপাশে ব্র্যাকেট থাকা আবশ্যক; -g curl-কে নির্দেশ দেয় সেগুলোকে URL গ্লোবিং সিনট্যাক্স হিসেবে গণ্য না করতে। সিঙ্গেল কোটেশন ডিফল্ট macOS শেলগুলোতে URL-কে অবিকৃত রাখে। Curl এই URL নিয়মগুলো নথিভুক্ত করে এবং হোস্টনেম রেজোলিউশন সীমাবদ্ধ করতে --ipv4 ও --ipv6 প্রদান করে। (curl URL সিনট্যাক্স, curl ম্যানুয়াল)

কানেকশন প্রত্যাখ্যান (connection refusal) সাধারণত বোঝায় যে সেই অ্যাড্রেস এবং পোর্টে কোনো লিসেনার কানেকশন গ্রহণ করছে না। টাইমআউট ইঙ্গিত দেয় যে নির্দিষ্ট সীমার মধ্যে কানেকশন সম্পূর্ণ হয়নি। যদি curl কোনো HTTP রেসপন্স প্রিন্ট করে, যার মধ্যে 404-এর মতো ত্রুটি স্ট্যাটাসও অন্তর্ভুক্ত, তবে TCP এবং HTTP কানেকশন সার্ভারে পৌঁছেছে; এটিকে IPv4/IPv6 কানেকশন ব্যর্থতা হিসেবে বিবেচনা না করে পাথ বা অ্যাপ্লিকেশন রেসপন্স তদন্ত করুন।

৩. প্রতিটি অ্যাড্রেসের সাথে localhost তুলনা করুন

এখন curl-এর IPv4 এবং IPv6 অপশন ব্যবহার করে হোস্টনেম টেস্ট করুন, তারপর কোনো ফ্যামিলি সীমাবদ্ধতা ছাড়াই চেষ্টা করুন:

curl -4 -v --connect-timeout 3 http://localhost:8000/
curl -6 -v --connect-timeout 3 http://localhost:8000/
curl -v --connect-timeout 3 http://localhost:8000/

Curl-এর -4 এবং -6 অপশন হোস্টনেমের জন্য শুধুমাত্র IPv4 বা শুধুমাত্র IPv6 অ্যাড্রেসের অনুরোধ করে। এর ডকুমেন্টেশনে উল্লেখ করা হয়েছে যে macOS শুধুমাত্র IPv6 রেজলভ অনুরোধে IPv4-ম্যাপ করা অ্যাড্রেস ফেরত দিতে পারে, তাই এই টেস্টগুলোকে প্রতিটি অ্যাপ্লিকেশনের রিজলভার আচরণের সম্পূর্ণ অডিট হিসেবে নয়, বরং curl-এর সীমাবদ্ধ কানেকশন প্রচেষ্টা হিসেবে বিবেচনা করুন। (curl ম্যানুয়াল)

কারণ নির্দিষ্ট করতে ফলাফলগুলো ব্যবহার করুন। যদি সরাসরি IPv4 টেস্ট কাজ করে এবং সরাসরি IPv6 টেস্ট ব্যর্থ হয়, যেখানে lsof শুধুমাত্র একটি IPv4 লিসেনার দেখায়, তবে IPv6 অ্যাক্সেস প্রয়োজন হলে সার্ভারটিকে IPv6-এও লিসেন করার জন্য কনফিগার করতে হতে পারে। শুধুমাত্র IPv6 লিসেনার কাজ করলে এর বিপরীতটি প্রযোজ্য। যদি উভয় সরাসরি টেস্ট কাজ করে কিন্তু localhost কাজ না করে, তবে ফোর্সড-ফ্যামিলি curl ফলাফলগুলো তুলনা করুন এবং অ্যাপ্লিকেশনের হোস্টনেম, প্রক্সি বা URL সেটিংস পরীক্ষা করুন। বিভিন্ন অ্যাপ্লিকেশন ভিন্নভাবে নাম সমাধান বা কানেক্ট করতে পারে; যে ডেভেলপাররা IPv4 এবং IPv6 উভয় পরিচালনা করতে সক্ষম অ্যাপ তৈরি করছেন, অ্যাপল তাদের জন্য অ্যাড্রেস-ফ্যামিলি-অজ্ঞেয়বাদী (agnostic) নেটওয়ার্কিং API ব্যবহারের সুপারিশ করে। (Apple Developer: Supporting IPv6-only Networks)

৪. প্রমাণ যেখানে নির্দেশ করে সেখানে সমাধান প্রয়োগ করুন

যখন শুধুমাত্র একটি লুপব্যাক অ্যাড্রেস কানেকশন গ্রহণ করে, তখন লোকাল সার্ভারের বাইন্ড-অ্যাড্রেস কনফিগারেশন পরিবর্তন করুন অথবা এটি প্রকৃতপক্ষে যে অ্যাড্রেস ফ্যামিলি সমর্থন করে তা ব্যবহার করুন। ধরে নেবেন না যে ম্যাকের Wi-Fi IPv4 বা IPv6 সেটিংস পরিবর্তন করলে লুপব্যাক লিসেনারের সমাধান হবে: লুপব্যাক রিকোয়েস্ট ম্যাককে নিজেই লক্ষ্য করে, অন্যদিকে সেই নেটওয়ার্ক সেটিংস একটি ইন্টারফেসের নেটওয়ার্ক সংযোগ কনফিগার করে। অ্যাপলের TCP/IP নিয়ন্ত্রণ একটি নির্বাচিত নেটওয়ার্ক সার্ভিসের জন্য IPv4 এবং IPv6 কনফিগার করতে পারে, কিন্তু তারা কোনো স্বতন্ত্র অ্যাপ্লিকেশনের লিসেনিং সকেট কনফিগার করে না। (Apple Support: Change TCP/IP settings on Mac)

যদি কোনো সরাসরি অ্যাড্রেসই কাজ না করে, তবে সার্ভারটি চলছে কিনা, পোর্টটি সঠিক কিনা এবং প্রত্যাশিত প্রোটোকলটি HTTP বা HTTPS কিনা তা যাচাই করুন। যদি একটি সরাসরি অ্যাড্রেস কাজ করে কিন্তু হোস্টনেম টেস্ট ভিন্ন হয়, তবে সার্ভার বাইন্ড অ্যাড্রেস নাকি ক্লায়েন্ট URL সমন্বয় করতে হবে তা নির্ধারণ করতে lsof অ্যাড্রেস এবং curl আউটপুট একসাথে ব্যবহার করুন। এই ক্রমটি প্রতিটি লোকালহোস্টের ব্যর্থতাকে DNS সমস্যা না ভেবে অনুপস্থিত লিসেনারকে ফ্যামিলি-নির্দিষ্ট বাইন্ড সমস্যা থেকে আলাদা করে।

সূত্র