curl ত্রুটি কোড: সম্পূর্ণ রেফারেন্স

দ্রুত রেফারেন্স টেবিল

ত্রুটি 6: হোস্ট রেজলভ করা যায়নি

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (6) Could not resolve host। curl হোস্টনেমকে IP অ্যাড্রেসে রেজলভ করতে পারেনি — কোনো সংযোগ চেষ্টা করার আগেই DNS লুকআপ ব্যর্থ হয়েছে।

কারণসমূহ

সবচেয়ে সাধারণ কারণগুলি হলো: হোস্টনেমে টাইপো (যেমন, api.example.com-এর বদলে curl https://apiexample.com), DNS সার্ভার সমস্যা (আপনার কনফিগার করা DNS ডাউন বা অপ্রাপ্য), কোনো নেটওয়ার্ক সংযোগ নেই (Wi-Fi বিচ্ছিন্ন, VPN সংযুক্ত নয়), অথবা ডোমেইনটি সত্যিই অস্তিত্বে নেই।

কীভাবে সমাধান করবেন

প্রথমে URL সঠিক কিনা যাচাই করুন। তারপর সরাসরি DNS রেজোলিউশন পরীক্ষা করুন: nslookup api.example.com অথবা dig api.example.com। DNS ব্যর্থ হলে, ভিন্ন DNS সার্ভার চেষ্টা করুন: curl --dns-servers 8.8.8.8 https://api.example.com। আপনার /etc/resolv.conf বা নেটওয়ার্ক সেটিংস পরীক্ষা করুন। কর্পোরেট VPN-এর পিছনে থাকলে, নিশ্চিত করুন অভ্যন্তরীণ DNS হোস্টটি রেজলভ করতে পারে।

$ curl https://api.exmple.com/users

ত্রুটি 7: সংযোগ ব্যর্থ

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (7) Failed to connect to host port: Connection refused। curl হোস্টনেম রেজলভ করেছে কিন্তু সার্ভারের সাথে TCP সংযোগ স্থাপন করতে পারেনি — সংযোগটি সক্রিয়ভাবে প্রত্যাখ্যাত হয়েছে অথবা TCP স্তরে টাইমআউট হয়েছে।

কারণসমূহ

সাধারণ কারণগুলির মধ্যে রয়েছে: সার্ভার ডাউন বা চালু নেই, একটি ফায়ারওয়াল পোর্ট ব্লক করছে (স্থানীয় ও সার্ভার-সাইড উভয় ফায়ারওয়াল পরীক্ষা করুন), পোর্ট ভুল (যেমন, সার্ভিস 8080-এ চলে কিন্তু আপনি 443-এ সংযোগ করছেন), অথবা সার্ভারের লিসেন ব্যাকলগ পূর্ণ অত্যধিক লোডের কারণে।

কীভাবে সমাধান করবেন

সার্ভার চালু আছে কিনা যাচাই করুন: ping api.example.com এবং telnet api.example.com 443। সঠিক পোর্ট খোলা আছে কিনা পরীক্ষা করুন: nmap -p 443 api.example.com। পরীক্ষার জন্য সাময়িকভাবে স্থানীয় ফায়ারওয়াল নিষ্ক্রিয় করুন। Docker ব্যবহার করলে, নিশ্চিত করুন কন্টেইনার পোর্ট পাবলিশ করা আছে। verbose মোডে চেষ্টা করুন: curl -v https://api.example.com ঠিক কোথায় সংযোগ ব্যর্থ হচ্ছে দেখতে।

$ curl https://localhost:8080/api

ত্রুটি 22: HTTP ত্রুটি ফেরত দিয়েছে

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (22) The requested URL returned error। সার্ভার একটি HTTP ত্রুটি স্ট্যাটাস কোড (4xx অথবা 5xx) ফেরত দিয়েছে এবং curl -f অথবা --fail দিয়ে চালানো হয়েছিল, যা curl-কে HTTP ত্রুটিগুলিকে ব্যর্থতা হিসেবে গণ্য করতে বলে।

কারণসমূহ

ত্রুটিটি HTTP স্ট্যাটাস কোড যেমন 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), অথবা 500 (Internal Server Error) দ্বারা ট্রিগার হয় — তবে শুধুমাত্র যখন --fail ব্যবহার করা হয়। --fail ছাড়া, HTTP ত্রুটিতেও curl কোড 0 দিয়ে বের হয়। সাধারণ কারণ: ভুল URL, অনুপস্থিত অথেন্টিকেশন, অপর্যাপ্ত অনুমতি, অথবা সার্ভার-সাইড বাগ।

কীভাবে সমাধান করবেন

সম্পূর্ণ রেসপন্স বডি দেখতে --fail ছাড়া curl চালান — এতে প্রায়ই প্রকৃত ত্রুটি বার্তা থাকে। HTTP স্ট্যাটাস কোড পরীক্ষা করুন: curl -w "%{http_code}" -o /dev/null -s URL। 401/403-এর জন্য: আপনার auth টোকেন অথবা API কী যাচাই করুন। 404-এর জন্য: URL পাথ পুনরায় পরীক্ষা করুন। 500-এর জন্য: সমস্যাটি সার্ভার-সাইডে।

$ curl --fail https://api.example.com/nonexistent

ত্রুটি 28: অপারেশন টাইমআউট হয়েছে

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (28) Operation timed out অথবা curl: (28) Connection timed out। অপারেশনটি অনুমোদিত সময়ের চেয়ে বেশি সময় নিয়েছে। এটি সবচেয়ে সাধারণ curl ত্রুটি — এটি DNS রেজোলিউশন, TCP সংযোগ, SSL হ্যান্ডশেক বা ডেটা ট্রান্সফারের সময় ঘটতে পারে।

কারণসমূহ

সাধারণ কারণগুলির মধ্যে রয়েছে: ধীর বা ওভারলোডেড সার্ভার সময়মতো সাড়া দিচ্ছে না, নেটওয়ার্ক কনজেশন বা প্যাকেট লস, ফায়ারওয়াল নীরবে প্যাকেট বাতিল করছে (কোনো প্রত্যাখ্যান নেই, শুধু নীরবতা), --connect-timeout বা --max-time দিয়ে সেট করা অতিরিক্ত কঠোর টাইমআউট মান, অথবা বিলম্ব সৃষ্টিকারী প্রক্সি ভুল কনফিগারেশন।

কীভাবে সমাধান করবেন

টাইমআউট বাড়ান: curl --connect-timeout 30 --max-time 120 URL। কোথায় আটকে আছে দেখতে verbose মোড ব্যবহার করুন: curl -v URL। নেটওয়ার্ক লেটেন্সি পরীক্ষা করুন: ping api.example.com এবং traceroute api.example.com। প্রক্সির পিছনে থাকলে, বাইপাস করার চেষ্টা করুন: curl --noproxy '*' URL। বড় ফাইল ট্রান্সফারের জন্য, --retry 3 এবং --retry-delay 5 ব্যবহার করার কথা ভাবুন।

$ curl --connect-timeout 5 https://slow-api.example.com/data

ত্রুটি 35: SSL সংযোগ ত্রুটি

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (35) SSL connect error। SSL/TLS হ্যান্ডশেক ব্যর্থ হয়েছে — curl সার্ভারের সাথে একটি নিরাপদ সংযোগ স্থাপন করতে পারেনি।

কারণসমূহ

সাধারণ কারণ: TLS সংস্করণ অমিল (সার্ভারের জন্য TLS 1.3 প্রয়োজন কিন্তু আপনার curl শুধুমাত্র TLS 1.2 পর্যন্ত সমর্থন করে), সাইফার স্যুট অসামঞ্জস্যতা, সার্ভার SSL ভুল কনফিগারেশন (হ্যান্ডশেকের সময় মেয়াদোত্তীর্ণ সার্ট প্রদর্শন, অসম্পূর্ণ চেইন), সার্ভার প্রদত্ত পোর্টে প্রকৃতপক্ষে HTTPS সমর্থন করে না, অথবা একটি প্রক্সি বা ফায়ারওয়াল SSL সংযোগে হস্তক্ষেপ করছে (MITM)।

কীভাবে সমাধান করবেন

নির্দিষ্ট TLS সংস্করণ জোর করুন: curl --tlsv1.2 URL অথবা curl --tlsv1.3 URL। সার্ভার কী সমর্থন করে পরীক্ষা করুন: openssl s_client -connect api.example.com:443। curl এবং OpenSSL সর্বশেষ সংস্করণে আপডেট করুন। সার্ভার যদি self-signed cert ব্যবহার করে, সেটি সাধারণত error 60 — error 35 সাধারণত একটি প্রোটোকল-স্তরের হ্যান্ডশেক ব্যর্থতা নির্দেশ করে।

$ curl https://legacy-server.example.com/api

ত্রুটি 56: রিসিভ ব্যর্থতা — সংযোগ রিসেট হয়েছে

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (56) Recv failure: Connection reset by peer। সংযোগটি সফলভাবে স্থাপিত হয়েছিল, কিন্তু ডেটা গ্রহণ ব্যর্থ হয়েছে — ট্রান্সফারের সময় সার্ভার অপ্রত্যাশিতভাবে সংযোগ বন্ধ বা রিসেট করে দিয়েছে।

কারণসমূহ

এটি প্রায়ই ঘটে যখন: সার্ভার ক্র্যাশ বা রিস্টার্ট হয় ট্রান্সফারের মাঝে, একটি লোড ব্যালেন্সার বা প্রক্সি সংযোগ ছেড়ে দেয় (নিষ্ক্রিয়তা টাইমআউট, রিকোয়েস্ট খুব বড়), একটি ফায়ারওয়াল দীর্ঘস্থায়ী সংযোগ বন্ধ করে দেয়, সার্ভারের keep-alive টাইমআউট প্রত্যাশার চেয়ে কম, অথবা ক্লায়েন্ট ও সার্ভারের মধ্যে নেটওয়ার্ক বিঘ্ন আছে।

কীভাবে সমাধান করবেন

আবার রিকোয়েস্ট চেষ্টা করুন — ক্ষণস্থায়ী নেটওয়ার্ক সমস্যা সবচেয়ে সাধারণ কারণ। verbose মোড ব্যবহার করুন: curl -v URL ব্যর্থতার সঠিক পয়েন্ট দেখতে। বড় আপলোডের সময় ত্রুটি ঘটলে, chunked ট্রান্সফার চেষ্টা করুন: curl -H "Transfer-Encoding: chunked" URL। RPC failed; curl 56 দেখানো Git অপারেশনের জন্য, বাফার বাড়ান: git config http.postBuffer 524288000।

$ curl https://api.example.com/large-download

ত্রুটি 60: SSL সার্টিফিকেট সমস্যা

এর অর্থ কী

আপনার টার্মিনালে দেখাচ্ছে curl: (60) SSL certificate problem: unable to get local issuer certificate। curl সার্ভারের SSL সার্টিফিকেট তার CA (Certificate Authority) বান্ডলের বিপরীতে যাচাই করতে পারেনি। TLS হ্যান্ডশেক প্রোটোকল স্তরে সম্পন্ন হয়েছে, কিন্তু সার্টিফিকেট যাচাইকরণ ব্যর্থ হয়েছে।

কারণসমূহ

সবচেয়ে সাধারণ কারণ: সার্ভার একটি self-signed সার্টিফিকেট ব্যবহার করে, সার্টিফিকেটটির মেয়াদ শেষ হয়ে গেছে, সার্টিফিকেট চেইন অসম্পূর্ণ (মধ্যবর্তী সার্টিফিকেট অনুপস্থিত), curl-এর CA বান্ডল পুরনো (পুরনো সিস্টেম বা Docker কন্টেইনারে সাধারণ), অথবা সার্টিফিকেটের Common Name / SAN অনুরোধিত হোস্টনেমের সাথে মেলে না।

কীভাবে সমাধান করবেন

CA বান্ডল আপডেট করুন: curl --cacert /path/to/cacert.pem URL। https://curl.se/ca/cacert.pem থেকে একটি আপডেটেড বান্ডল ডাউনলোড করুন। সমস্যা নির্ণয়ের জন্য: openssl s_client -connect api.example.com:443 -showcerts। ডেভেলপমেন্টে self-signed cert-এর জন্য, curl -k URL ব্যবহার করুন (কখনোই প্রোডাকশনে নয় — এটি সমস্ত সার্টিফিকেট যাচাইকরণ নিষ্ক্রিয় করে)। Docker-এ, ca-certificates প্যাকেজ ইনস্টল করুন।

$ curl https://self-signed.example.com/api

অন্যান্য ত্রুটি কোড

curl ত্রুটি কীভাবে ডিবাগ করবেন

curl ব্যর্থ হলে, এই তিনটি ফ্ল্যাগ আপনাকে দ্রুত মূল কারণ সনাক্ত করতে সাহায্য করে — DNS রেজোলিউশন থেকে SSL হ্যান্ডশেক থেকে রেসপন্স পেলোড পর্যন্ত।

1. 1

   verbose আউটপুট সক্রিয় করুন

   সম্পূর্ণ রিকোয়েস্ট/রেসপন্স চক্র দেখতে curl -v URL চালান: DNS রেজোলিউশন, TCP সংযোগ, TLS হ্যান্ডশেক, পাঠানো রিকোয়েস্ট হেডার এবং প্রাপ্ত রেসপন্স হেডার। এটি সবচেয়ে কার্যকর ডিবাগিং ফ্ল্যাগ।

2. 2

   HTTP স্ট্যাটাস কোড পরীক্ষা করুন

   রেসপন্স বডি ছাড়াই শুধুমাত্র HTTP স্ট্যাটাস কোড (200, 404, 500, ইত্যাদি) পেতে curl -o /dev/null -s -w "%{http_code}" URL চালান। দ্রুত হেলথ চেক এবং স্ক্রিপ্টিংয়ের জন্য উপকারী।

3. 3

   নীরবে ত্রুটি দেখান

   প্রগ্রেস বার দমন করতে (-s) কিন্তু তবুও ত্রুটি দেখাতে (-S) curl -sS URL চালান। স্ক্রিপ্টের জন্য আদর্শ যেখানে আপনি পরিষ্কার আউটপুট চান কিন্তু ব্যর্থতা ধরতে চান।

সচরাচর জিজ্ঞাসিত প্রশ্নাবলী