Nginx বনাম Caddy: 2025 সালে কোন ওয়েব সার্ভার ব্যবহার করবেন?

Nginx vs Caddy: আপনি কী তুলনা করছেন

Nginx এবং Caddy—উভয়ই আপনার নিজস্ব মেশিনে (VM, বেয়ার মেটাল সার্ভার, বা কন্টেইনার) চালানোর জন্য ওয়েব সার্ভার—যা দিয়ে আপনি একটি সাইট বা অ্যাপ ইন্টারনেটে প্রকাশ করেন।

সাধারণত এগুলো ব্যবহৃত হয়:

• স্ট্যাটিক সাইট: HTML/CSS/JS ফাইলগুলো দক্ষতার সঙ্গে পরিবেশন করা
• রিভার্স প্রোক্সি: একটি ব্যবহারকারী-বান্ধব পাবলিক URL সামনে রেখে অ্যাপ (Node, Python, Go, PHP-FPM ইত্যাদি) সার্ভ করা
• লোড ব্যালান্সিং: একাধিক অ্যাপ ইনস্ট্যান্সে ট্রাফিক বণ্টন করা

কেন মানুষ এগুলোকে তুলনা করে

বেশিরভাগ তুলনা মূলত এক ধরনের ট্রেড‑অফ নিয়ে: কত দ্রুত একটি নিরাপদ, কাজ করা সেটআপ পাবেন বনাম প্রতিটি বিস্তারিত নিয়ন্ত্রণ করতে কতটা প্রয়োজন।

Caddy সাধারণত তখনই নির্বাচিত হয় যখন আপনি কম কনফিগারেশনে আধুনিক ডিফল্ট চান—বিশেষ করে HTTPS সংক্রান্ত—বিনা ঝামেলায়।

Nginx নির্বাচিত হয় যখন আপনি একটি পরিণত, ব্যাপকভাবে স্থাপিত সার্ভার চান যার কনফিগারেশন স্টাইল অত্যন্ত নমনীয় হতে পারে যদি আপনি তা জানেন।

এই গাইড কার জন্য

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

আমরা কী রাখব এবং কী রাখতে নয়

আমরা মনোযোগ দেব বাস্তব ডেপ্লয়মেন্ট উদ্বেগে: কনফিগারেশন এরগনমিক্স, HTTPS ও সার্টিফিকেট, রিভার্স প্রোক্সি আচরণ, পারফরম্যান্স ভিত্তি, সিকিউরিটি ডিফল্ট, এবং অপারেশন্স।

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

শুরু করা ও প্রথম দিনের অভিজ্ঞতা

ইনস্টল ও চালানো: ডিফল্ট আচরণ ও প্রথম কাজ করা সাইট

Nginx সর্বত্র সহজলভ্য (লিনাক্স রিপোস, কন্টেইনার, ম্যানেজড হোস্ট)। ইনস্টল করার পরে প্রায়শই ডিস্ট্রো‑নির্দিষ্ট ডিরেক্টরি থেকে “Welcome to nginx!” পেজ আসে। আপনার প্রথম প্রকৃত সাইট অনলাইনে আনার জন্য সাধারণত একটি server block ফাইল তৈরি, সক্রিয় করা, কনফিগ টেস্ট করা, এবং রিলোড করা লাগে।

Caddy ইনস্টল করতেও সমান সহজ (প্যাকেজ, সিঙ্গেল বাইনারি, Docker), কিন্তু প্রথম-চলানোর অভিজ্ঞতা বেশি “বাটারিগুলো ইনক্লুডেড”। একটি কম-মাত্রার Caddyfile কয়েক মিনিটে একটি সাইট বা রিভার্স প্রোক্সি সার্ভ করতে পারে, এবং ডিফল্টগুলো নিরাপদ, আধুনিক HTTPS-এর দিকে লক্ষ রাখে।

শেখার কার্ভ: কনফিগ স্টাইল ও সাধারণ ফাঁদ

Nginx কনফিগ শক্তিশালী, কিন্তু বিগিনাররা প্রায়শই বাধা পায়:

• কনফিগ ফাইলগুলো কোথায় থাকে এবং includes কিভাবে কাজ করে
• সূক্ষ্ম মিলের নিয়ম (location precedence)
• রিলোড করার আগে nginx -t ভুলে যাওয়া

Caddy এর Caddyfile ইচ্ছা‑ভিত্তিকভাবে পড়তে সহজ ("এটাকে প্রোক্সি কর"), যা সাধারণ সেটআপে ভুল কমায়। ট্রেড‑অফ হলো যখন আপনি খুব নির্দিষ্ট আচরণ চান, তখন হয়তো Caddy‑র অন্তর্নিহিত JSON কনফিগ বা মডিউল ধারণা জানতে হবে।

একটি নতুন ডোমেইনে HTTPS চালু করতে সময়

Caddy দিয়ে পাবলিক ডোমেইনের জন্য HTTPS প্রায়ই এক লাইনে হয়ে যায়: সাইট অ্যাড্রেস দিন, DNS পয়েন্ট করুন, Caddy চালান—সার্টিফিকেট নিজে অনুরোধ ও নবায়ন করে।

Nginx এ HTTPS সাধারণত সার্টিফিকেট পদ্ধতি নির্বাচন (উদাহরণ: Certbot), ফাইল পাথ যুক্ত করা, এবং নবায়ন ব্যবস্থা করা প্রয়োজন। কঠিন নয়, কিন্তু ধাপে ধাপে বেশি এবং ভুল হওয়ার জায়গা বেশি।

লোকাল ডেভ অভিজ্ঞতা (localhost, self-signed, trust)

লোকাল ডেভের জন্য Caddy caddy trust দিয়ে লোকাল সার্টিফিকেট তৈরি ও ট্রাস্ট করতে পারে, ফলে https://localhost প্রোডাকশনের কাছাকাছি অনুভূত হয়।

Nginx-এ লোকাল HTTPS সাধারণত ম্যানুয়াল (সেলফ‑সাইনড সার্টিফিকেট তৈরি, কনফিগ করা, তারপর ব্রাউজার সতর্কতা মেনে নেওয়া বা লোকাল CA ইনস্টল করা)। অনেক টিম লোকাল HTTPS এড়িয়ে যায়, যা পরে কুকি, রিডাইরেক্ট, এবং মিক্সড‑কনটেন্ট সমস্যা উন্মোচিত করতে পারে।

কনফিগারেশন স্টাইল ও পাঠযোগ্যতা

কনফিগারেশন হল যেখানে Nginx ও Caddy সবচেয়ে আলাদা মনে হয়। Nginx স্পষ্ট, নেস্টেড স্ট্রাকচার ও অনেক ডিরেকটিভ পছন্দ করে। Caddy ছোট, পড়তে সহজ “ইচ্ছা‑প্রথম” সিনট্যাক্স পছন্দ করে যা স্ক্যান করতে সহজ—বিশেষ করে যখন আপনি কয়েকটি সাইট ম্যানেজ করেন।

Nginx: server blocks, locations, এবং includes

Nginx কনফিগ contexts-এর উপর গঠিত। বেশিরভাগ ওয়েব অ্যাপ এক বা একাধিক server {} ব্লক (ভার্চুয়াল হোস্ট) পায়, এবং তাদের মধ্যে একাধিক location {} ব্লক যা পাথ মেলে।

স্ট্রাকচার শক্তিশালী, কিন্তু নিয়ম বাড়লে পড়া কষ্টকর হয় (regex locations, একাধিক if স্টেটমেন্ট, লম্বা হেডার তালিকা)। প্রধান রক্ষণাবেক্ষণ টুল হলো includes: বড় কনফিগগুলো ছোট ফাইলে ভাগ করুন এবং ধারাবাহিক লেআউট রাখুন।

একই সার্ভারে একাধিক সাইট সাধারণত একাধিক server {} ব্লক মানে (প্রতিটি সাইটের জন্য এক ফাইল), প্লাস শেয়ার্ড স্নিপেট:

# /etc/nginx/conf.d/example.conf
server {
  listen 80;
  server_name example.com www.example.com;

  include /etc/nginx/snippets/security-headers.conf;

  location / {
    proxy_pass http://app_upstream;
    include /etc/nginx/snippets/proxy.conf;
  }
}

একটা ব্যবহারিক নিয়ম: nginx.conf-কে “রুট ওয়ারিং” হিসেবে দেখুন, এবং অ্যাপ/সাইট‑নির্দিষ্টগুলো /etc/nginx/conf.d/ (অথবা sites-available/sites-enabled, ডিস্ট্রো অনুসারে) রাখুন।

Caddy: Caddyfile ডিরেকটিভ ও পাঠযোগ্যতা

Caddy-এর Caddyfile আরও যেন একটি চেকলিস্ট—আপনি কি করতে চান তা বলার মতো। আপনি একটি site block (সাধারণত ডোমেইন) ডিক্লেয়ার করেন, তারপর reverse_proxy, file_server, বা encode মতো ডিরেকটিভ যোগ করেন।

অনেক টিমের জন্য মূল জয় হলো “হ্যাপি পাথ” সংক্ষিপ্ত ও পাঠযোগ্য থাকে—এবং সাধারণ ফিচার যোগ করলেও এটা পরিষ্কার থাকে:

example.com {
  reverse_proxy localhost:3000
  encode zstd gzip
  header {
    Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\"
  }
}

একই সার্ভারে একাধিক সাইট সাধারণত একই ফাইলে একাধিক site block (অথবা import করা ফাইল) রাখা সহজ এবং রিভিউতে স্ক্যান করা সুবিধাজনক।

প্রকল্প বাড়লে কনফিগ বজায় রাখা

• স্ট্যান্ডার্ডাইজ স্ট্রাকচার আগে থেকেই। Nginx‑এ সিদ্ধান্ত নিন প্রতি‑সাইট ফাইল + শেয়ার্ড স্নিপেট কেমন হবে। Caddy‑তে ঠিক করুন প্রতিটি সাইট আলাদা ফাইল পাবে কি না এবং import দিয়ে টেনে নেবেন কি না।
• শেয়ার্ড স্নিপেটগুলো উদ্দেশ্যভিত্তিক নামক করুন। “proxy defaults”, “security headers”, “static caching” — সাইটগুলির মধ্যে ব্লকগুলো কপি করবেন না।
• পরবর্তী রিডারের জন্য অপ্টিমাইজ করুন। Nginx প্রায় কিছুই প্রকাশ করতে পারে, কিন্তু জটিল location ম্যাচ পরে সবচেয়ে কষ্টকর। Caddy সহজ প্যাটার্ন উৎসাহ দেয়; যদি আপনি তাদের ছাড়িয়ে যান, মন্তব্যে ইন্টেন্ট ডকুমেন্ট করুন।

পরিষ্কারতা অগ্রাধিকার হলে Caddy‑র Caddyfile খুব শক্ত প্রতিযোগী। যদি আপনি সূক্ষ্ম নিয়ন্ত্রণ চান এবং একটু বেশি স্ট্রাকচার ও শব্দ‑বহুল শৈলী সমস্যা না হয়, Nginx শক্ত অবস্থানেই আছে।

HTTPS ও সার্টিফিকেট ব্যবস্থাপনা

HTTPS‑এ দৈনন্দিন অভিজ্ঞতা Nginx ও Caddy‑এর মধ্যে সবচেয়ে ভিন্ন। উভয়ই চমৎকার TLS পরিবেশন করতে পারে; পার্থক্য হলো কাজ আপনি কতটা করবেন—এবং কনফিগ ড্রিফট ঘটবার সম্ভাবনা কতটা থাকবে।

Caddy: ডিফল্টভাবে স্বয়ংক্রিয় HTTPS

Caddy‑র প্রধান বৈশিষ্ট্য হল স্বয়ংক্রিয় HTTPS। যদি Caddy হোস্টনেম বুঝতে পারে এবং তা পাবলিকভাবে প্রবেশযোগ্য হয়, এটি সাধারণত:

• সার্টিফিকেট অর্জন করে (সাধারণত ACME/Let’s Encrypt ব্যবহার করে)
• মেয়াদ শেষের আগে অটোম্যাটিক নবায়ন করে
• আধুনিক TLS ডিফল্ট সক্রিয় করে যাতে আপনাকে সাইফার সেট আপ করতে না হয়

প্র্যাকটিসে, আপনি সাইট কনফিগ করুন, Caddy চালান, এবং সাধারণ পাবলিক ডোমেইনের জন্য HTTPS “স্বয়ংক্রিয়ভাবে ঘটে”। এটি HTTP→HTTPS রিডাইরেক্টও সাধারণত স্বয়ংক্রিয়ভাবে হ্যান্ডেল করে, যা অনেক ভুল কমায়।

Nginx: HTTPS শক্তিশালী, কিন্তু প্রায়ই ম্যানুয়াল

Nginx আশা করে আপনি TLS নিজে ওয়্যার করবেন। আপনাকে করতে হবে:

• সার্টিফিকেট সংগ্রহ (ACME ক্লায়েন্ট যেমন Certbot, বা আপনার প্রোভাইডার)
• Nginx‑এ ssl_certificate এবং ssl_certificate_key পাথ সেট করা
• নবায়নের পরে Nginx রিলোড করা নিশ্চিত করা

এটি অনেকটাই ফ্লেক্সিবল, কিন্তু একটি ধাপ ভুলে যাওয়া সহজ—বিশেষত অটোমেশন ও রিলোড নিয়ে।

রিডাইরেক্ট ও সাধারণ ভুল

ক্লাসিক ফাঁদ হল ভুলভাবে হ্যান্ডেল করা রিডাইরেক্ট:

• কেবল হোমপেজ রিডাইরেক্ট করা, সব পাথ না করা
• রিডাইরেক্ট লুপ তৈরি করা (উদাহরণ: CDN বা লোড বালান্সারের পিছনে)
• উপরের দিকে TLS টার্মিনেট করা হলেও ভুল স্কীমের ওপর ভিত্তি করে রিডাইরেক্ট করা

Caddy সংবেদনশীল ডিফল্ট দিয়ে এই ভুলগুলো কমায়। Nginx‑এ আপনি স্পষ্ট হতে হবে এবং এন্ড‑টু‑এন্ড আচরণ যাচাই করবেন।

কাস্টম সার্টিফিকেট ও ইন্টারনাল PKI

কাস্টম সার্টিফিকেট (কমার্শিয়াল, ওয়াইল্ডকার্ড, প্রাইভেট CA)‑এর জন্য উভয় সার্ভার ভালভাবে কাজ করে।

• Nginx সরল: আপনি সার্টিফিকেট/কী ফাইল দেবেন এবং TLS কনফিগ করবেন।
• Caddy কাস্টম সার্টিফিকেটও সাপোর্ট করে, এবং ইন্টারনাল PKI পরিস্থিতিতেও ব্যবহার করা যায় (প্রাইভেট এনভায়রনমেন্টে উপকারী), তবে ক্লায়েন্ট ও সার্ভিসগুলিতে ট্রাস্ট বিতরণ সম্পর্কে পরিকল্পনা করতে হবে।

রিভার্স প্রোক্সি ফিচার যা বাস্তবে গুরুত্বপূর্ণ

অধিকাংশ টিম “Hello World” জন্য সার্ভার নির্বাচন করে না। তারা দৈনন্দিন প্রোক্সি কাজের জন্য নির্বাচন করে: ক্লায়েন্ট বিবরণ ঠিক রাখা, লং‑লিভড সংযোগ সাপোর্ট করা, এবং imperfect ট্রাফিকের সময় অ্যাপগুলো স্থিতিশীল রাখা।

রিভার্স প্রোক্সি বেসিক্স (হেডার, রিয়েল IP, WebSockets)

Nginx ও Caddy—উভয়ই আপনার অ্যাপের সামনে বসে অনুরোধ ক্লিনলি ফরওয়ার্ড করতে পারে, কিন্তু বিবরণগুলো গুরুত্বপূর্ণ।

ভালো রিভার্স প্রোক্সি সেটআপ সাধারণত নিশ্চিত করে:

• সঠিক ফরওয়ার্ড হেডার যেমন Host, X-Forwarded-Proto, ও X-Forwarded-For, যাতে আপনার অ্যাপ সঠিক রিডাইরেক্ট ও লগ বানাতে পারে।
• রিয়েল ক্লায়েন্ট IP হ্যান্ডলিং, যা রেট লিমিটিং, অডিটিং, জিও নিয়ম, এবং ফ্রেমওয়ার্কের “trusted proxy” সেটিংসকে প্রভাবিত করে।
• WebSockets সাপোর্ট চ্যাট, ড্যাশবোর্ড এবং রিয়েলটাইম ফিচারের জন্য। Nginx‑এ সাধারণত Upgrade/Connection হেডার স্পষ্টভাবে হ্যান্ডেল করতে হয়; Caddy প্রোক্সি করলে সাধারণত এটি স্বয়ংক্রিয়ভাবে হ্যান্ডেল করে।

লোড ব্যালান্সিং ও হেলথ চেক

একাধিক অ্যাপ ইনস্ট্যান্স থাকলে উভয় সার্ভার ট্রাফিক বিতরণ করতে পারে। Nginx ওয়েটেড ব্যালান্সিং ও সূক্ষ্ম নিয়ন্ত্রণের দীর্ঘ সময়ের প্যাটার্ন আছে, আর Caddy‑র লোড ব্যালান্সিং সাধারণত সাধারণ সেটআপের জন্য সরল।

অপারেশনালভাবে সত্যিকারের পার্থক্য হল হেলথ চেক: আপনি চান অস্বাস্থ্যকর ইনস্ট্যান্স দ্রুত অপসারণ করা হোক, এবং টাইমআউট টিউনিং যাতে ব্যবহারকারী মৃত ব্যাকএন্ডে অপেক্ষা না করে।

টাইমআউট, বাফারিং, ও বড় আপলোড

বাস্তব অ্যাপ এসব এজ কেস পায়: ধীর ক্লায়েন্ট, দীর্ঘ API কল, সার্ভার‑সেন্ট ইভেন্টস, বড় আপলোড।

মনোযোগ দিন:

• রিড/রাইট টাইমআউট প্রোক্সি ও আপস্ট্রিমের মধ্যে
• রিকোয়েস্ট/রেসপন্স বাফারিং (সঠিক হলে স্থিরতার জন্য ভাল, কিন্তু স্ট্রিমিং ভাঙ্গাতে পারে)
• বডি সাইজ লিমিট এবং বড় ফাইলগুলোর টেম্প স্টোরেজ আচরণ

রেট লিমিটিং ও বেসিক সুরক্ষাসমূহ

ডিফল্টভাবে কোনটিও ফুল‑WAF নয়, তবে উভয়ই ব্যবহারিক গার্ডরেইল দেয়: প্রতি‑IP অনুরোধ সীমা, সংযোগ ক্যাপ, এবং বেসিক হেডার সেন্সিবিলিটি চেক। নিরাপত্তা অবস্থান তুলনা করলে এটাকে আপনার বিস্তৃত চেকলিস্টের সঙ্গে জোড়া লাগান: /blog/nginx-vs-caddy-security।

পারফরম্যান্স ও প্রোটোকল সাপোর্ট

পারফরম্যান্স কেবল “প্রতি সেকেন্ড অনুরোধ” নয়। এটি কত দ্রুত ব্যবহারকারী কিছু ব্যবহারযোগ্য দেখে, আপনি কীভাবে স্ট্যাটিক অ্যাসেট দক্ষভাবে পরিবেশন করেন, এবং আপনার প্রোটোকল স্ট্যাক কতটা আধুনিক।

স্ট্যাটিক ফাইল: ক্যাশিং হেডার ও কম্প্রেশন

স্ট্যাটিক সাইট হোস্টিংয়ের জন্য (CSS, JS, ছবি) উভয়ই ভাল কনফিগে দ্রুত হতে পারে।

Nginx আপনাকে ক্যাশিং হেডার নিয়ে সূক্ষ্ম নিয়ন্ত্রণ দেয় (উদাহরণ: হ্যাশ করা অ্যাসেটগুলোর জন্য দীর্ঘ‑লাইফ, HTML-এর জন্য সংক্ষিপ্ত)। Caddy একই করতে পারে, তবে আপনি হয়তো স্নিপেট বা রুট ম্যাচার ব্যবহার করবেন একই ইরাদা প্রকাশ করার জন্য।

কম্প্রেশন একটি ট্রেড‑অফ:

• Gzip বিস্তৃতভাবে সমর্থিত এবং সাধারণত নিরাপদ ডিফল্ট।
• Brotli টেক্সট অ্যাসেট কমায়, ধীর নেটওয়ার্কে সহায়ক, কিন্তু CPU খরচ বেশি।

ক্ষুদ্র সাইটে Brotli ব্যবহার সাধারণত ক্ষতি করে না এবং পেজগুলো দ্রুত অনুভূত হতে পারে। বড় ট্রাফিক সাইটে CPU‑হেডরুম পরিমাপ করুন বা আগেই কনটেন্ট প্রি‑কমপ্রেস করুন বা এজ/ CDN‑এ অফলোড করুন।

HTTP/2 ও HTTP/3: ব্যবহারকারীরা কী লক্ষ্য করবে

HTTP/2 আধুনিক ব্রাউজারের জন্য বেসলাইন এবং অনেক ছোট অ্যাসেট একক কানেকশনে দ্রুততর করে। উভয় সার্ভার এটি সাপোর্ট করে।

HTTP/3 (QUIC) ফ্ল্যাকি মোবাইল নেটওয়ার্কে পারফরম্যান্স বাড়াতে পারে—প্যাকেট লস ও সংযোগ হ্যান্ডশেকের ব্যথা কমায়। Caddy সাধারণত HTTP/3 ট্রাই করা সহজ করে; Nginx‑এর সাপোর্ট বিল্ড অনুযায়ী ভিন্ন হতে পারে এবং নির্দিষ্ট প্যাকেজ দরকার হতে পারে।

SPA ও ফ্যালব্যাক রুটস

সিঙ্গেল‑পেজ অ্যাপ সার্ভ করলে সাধারণত “ফাইল চেষ্টা করো, না হলে /index.html পরিবেশন করো” প্রয়োজন। উভয়ই এটা ভালোভাবে করতে পারে, কিন্তু নিশ্চিত করুন API রুটগুলো দুর্ঘটনাক্রমে SPA‑কে ফ্যালব্যাক না করে এবং প্রকৃত 404 গোপন না হয়।

সিকিউরিটি ডিফল্ট ও হার্ডেনিং চেকলিস্ট

উভয় সার্ভারই ভালোভাবে হার্ডেন করা যায়, কিন্তু তাদের ডিফল্ট আলাদা।

Caddy অনেক সাধারণ ডেপ্লয়মেন্টে “secure‑by‑default”: আধুনিক TLS স্বয়ংক্রিয়ভাবে চালু করে, সার্টিফিকেট নবায়ন করে, এবং HTTPS‑only সেটআপ উদ্দীপনা দেয়। Nginx নমনীয় এবং ব্যাপকভাবে ব্যবহৃত, কিন্তু সাধারণত TLS, হেডার, ও অ্যাক্সেস কন্ট্রোল স্পষ্টভাবে কনফিগ করতে হবে।

সাধারণ ডিফল্ট (এবং আপনি যা এখনও কনফিগ করবেন)

• অপ্রয়োজনীয় এনডপয়েন্ট/ফিচার নিষ্ক্রিয় করুন: স্যাম্পল সাইট, অ্যাডমিন UI, বা ডিবাগ রুট প্রোডাকশনে পাঠাবেন না।
• এক্সপোজার সীমিত করুন: ইনটারনাল সার্ভিসগুলো প্রাইভেট ইন্টারফেসে বেঁধে দিন, শুধুমাত্র যা পাবলিক হওয়া দরকার তা প্রকাশ করুন।
• ডিপেন্ডেন্সি আপডেট রাখুন: সার্ভার ও মডিউল নিয়মিত আপডেট করুন।

TLS ভার্সন ও সাইফার পছন্দ (সরল রাখুন)

• TLS 1.2 ও TLS 1.3 পছন্দ করুন; পুরনো ভার্সন এড়িয়ে চলুন।
• সার্ভারের আধুনিক ডিফল্ট ব্যবহার করুন যতক্ষণ না কঠোর কমপ্লায়েন্স দরকার।
• Nginx‑এ স্পষ্টভাবে প্রটোকল সেট করুন এবং হোস্টগুলোর মধ্যে কনফিগ মিল রাখুন।

বেসিক অথেন্টিকেশন, IP allow/deny, ও অ্যাডমিন রুট রক্ষা

ইন্টারনাল টুল (মেট্রিক্স, অ্যাডমিন প্যানেল, প্রিভিউ) গুলোকে অথেন্টিকেশন ও/অথবা IP allowlist দিয়ে রক্ষা করুন।

Caddy উদাহরণ:

admin.example.com {
  basicauth {
    admin $2a$10$..............................................
  }
  reverse_proxy 127.0.0.1:9000
}

Nginx‑এ auth_basic বা allow/deny প্রয়োগ করুন সেই নির্দিষ্ট location ব্লকে যা সংবেদনশীল রুট প্রকাশ করে।

সিকিউরিটি হেডার: HSTS, CSP বেসিক, ও নিরাপদ ডিফল্ট

কমন রিস্ক কমাতে শুরু করুন:

• HSTS (HTTPS স্থিতিশীল হলে): Strict-Transport-Security: max-age=31536000; includeSubDomains
• Clickjacking প্রতিরোধ: X-Frame-Options: DENY (অথবা প্রয়োজন হলে SAMEORIGIN)
• MIME sniffing বন্ধ: X-Content-Type-Options: nosniff
• CSP (বেসিক): একটি কনসার্ভেটিভ পলিসি দিয়ে শুরু করুন এবং প্রয়োজন অনুযায়ী আলগা করুন (CSP ভুল করলে সাইট ভেঙে দিতে পারে)।

হার্ডেনিং‑এ এক “পারফেক্ট” কনফিগ চাই না; বরং ধারাবাহিকভাবে কনফ্রোল প্রযোজ্য সব এন্ডপয়েন্টে প্রয়োগ করাই মূল কথা।

ইকোসিস্টেম, মডিউল, ও এক্সটেনসিবিলিটি

দীর্ঘমেয়াদী অভিজ্ঞতা প্রায়শই কোর ফিচারের চেয়ে বেশি নির্ভর করে আশেপাশের ইকোসিস্টেমে: মডিউল, কপি করার মতো উদাহরণ, এবং যখন প্রয়োজন তখন বর্ধন করা কতটা সহজ।

Nginx: পরিণত মডিউল ও বিশাল নলেজ বেস

Nginx‑এর ইকোসিস্টেম বহু বছর ধরে গড়ে উঠেছে। প্রচুর অফিসিয়াল ও থার্ড‑পার্টি মডিউল আছে, এবং কমিউনিটি কনফিগারেশন উদাহরণের পরিমাণ বিপুল (ব্লগ পোস্ট, GitHub gists, ভেন্ডর ডকস)। যখন আপনাকে একটি নির্দিষ্ট সক্ষমতা লাগবে—অ্যাডভান্সড ক্যাশিং, সূক্ষ্ম লোড ব্যালান্সিং, অথবা জনপ্রিয় অ্যাপের জন্য ইন্টিগ্রেশন—সেটার সমাধান খুঁজে পাওয়ার সম্ভাবনা বেশি।

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

Caddy: এক্সটেনশন শক্তিশালী—বিবেচনা করে ব্যবহার করুন

Caddy‑র কোর অনেক কিছু কভার করে (বিশেষত HTTPS ও রিভার্স প্রোক্সি), কিন্তু যদি অপ্রচলিত অথেন্টিকেশন পদ্ধতি, অদ্ভুত আপস্ট্রিম ডিসকভারি, বা কাস্টম রিকোয়েস্ট হ্যান্ডলিং দরকার হয় তবে এক্সটেনশন লাগবে।

এক্সটেনশন মূল্যায়ন করার সময় দেখুন:

• মেইনটেন্যান্স সিগন্যাল: সাম্প্রতিক রিলিজ, সক্রিয় ইস্যু/PR, পরিষ্কার মালিকানা
• সিকিউরিটি অবস্থান: কম অনুমতি, ডকুমেন্টেড থ্রেট মডেল, সংবেদনশীল ডিফল্ট নয়
• অপারেশনাল ফিট: CI তে বিল্ড/রিলিজ প্রসেস পুনরুৎপাদনযোগ্য

অপারেশনাল ঝুঁকি পরিচালনা ও লক‑ইন এড়ানো

অপ্রচলিত প্লাগইনে নির্ভরশীল হলে আপগ্রেড ঝুঁকি বাড়ে: API অসঙ্গতি বা এ্যব্যান্ডনমেন্ট আপনাকে পুরনো ভার্সনে ফেঁসে রাখতে পারে। নমনীয় থাকতে, কোরে উপলব্ধ ফিচার অগ্রাধিকার দিন, কনফিগ পোর্টেবল রাখুন (ইনটেন্ট ডকুমেন্ট করুন কেবল সিনট্যাক্স নয়), এবং “স্পেশাল সসা” আলাদা পরিষেবা দিয়ে আবদ্ধ রাখুন (উদাহরণ: অথ মানে একটি ডেডিকেটেড সার্ভিস)। সন্দেহ হলে, আপনার প্রকৃত অ্যাপ দিয়ে উভয় সার্ভারে প্রোটোটাইপ করুন।

অপারেশন: লগিং, মনিটরিং, ও সেফ রিলোড

ওয়েব সার্ভার চালানো মানেই শুধু সেট করে রাখা নয়। দিন‑দুই কাজ—লোগ, মেট্রিক্স, ও নিরাপদ পরিবর্তন—ওই জায়গা যেখানে Nginx ও Caddy আলাদা অনুভূত হয়।

লগিং ও ট্রাবলশুটিং

Nginx সাধারণত আলাদা অ্যাক্সেস ও এরর লগ লিখে, কাস্টমাইজযোগ্য ফরম্যাট সহ:

• অ্যাক্সেস লগ: রিকোয়েস্ট/রেসপন্স ডিটেইল, টাইমিং, আপস্ট্রিম স্ট্যাটাস
• এরর লগ: কনফিগ ইস্যু, আপস্ট্রিম ত্রুটি, TLS ত্রুটি ইত্যাদি

আপনি log_format টিউন করে ইনসিডেন্ট ওয়ার্কফ্লো অনুযায়ী তথ্য যোগ করতে পারবেন (উদাহরণ: আপস্ট্রিম টাইমিং)। ট্রাবলশুটিং প্রায়ই অ্যাক্সেস লগ স্পাইক ও নির্দিষ্ট এরর লগ মেসেজ কোরিলেট করে হয়।

Caddy ডিফল্টে স্ট্রাকচার্ড লগিং (সাধারণত JSON) দেয়, যা লগ অ্যাগ্রিগেশন টুলে ফিল্টার করা সহজ করে। যদি আপনি টেক্সট লগ পছন্দ করেন, সেটা কনফিগ করা যায়, কিন্তু বেশিরভাগ টিম স্ট্রাকচার্ড লগে ঝুঁকে পড়ে দ্রুত ফিল্টারিংয়ের জন্য।

মেট্রিক্স ও অবজার্ভেবিলিটি (উচ্চ স্তর)

Nginx সাধারণত বিল্ট‑ইন স্ট্যাটাস এন্ডপয়েন্ট (অথবা কমার্শিয়াল ফিচার) + Prometheus এক্সপোর্টার/এজেন্টের মাধ্যমে মেট্রিক্স সংগ্রহ করে।

Caddy অপারেশনাল সিগন্যাল তার অ্যাডমিন API দিয়ে প্রকাশ করতে পারে এবং সাধারণ অবজার্ভেবিলিটি স্ট্যাকের সঙ্গে ইন্টিগ্রেট করা যায়; টিমরা সাধারণত Prometheus‑স্টাইল স্ক্র্যাপিং চাইলে মেট্রিক্স মডিউল/এক্সপোর্টার যোগ করে।

সেফ রিলোড ও কনফিগ ভ্যালিডেশন

সার্ভার যাইই হোক, একটিভ ওয়ার্কফ্লো লক্ষ্য করুন: ভ্যালিডেট → রিলোড।

Nginx-এর পরিচিত প্রক্রিয়া:

• Validate: nginx -t
• Reload without dropping connections: nginx -s reload (অথবা systemctl reload nginx)

Caddy নিজের রিলোড মেকানিজম ও কনফিগ অ্যাডাপটেশন/ভ্যালিডেশন ওয়ার্কফ্লো সমর্থন করে (বিশেষত যদি আপনি JSON কনফিগ জেনারেট করেন)। মূল বিষয় অভ্যাস: ইনপুট ভ্যালিডেট করুন ও পরিবর্তন রিভার্সিবল রাখুন।

ব্যাকআপ ও চেঞ্জ ম্যানেজমেন্ট

উভয় সার্ভারের জন্য কনফিগকে কোড হিসেবে বিবেচনা করুন:

• কনফিগগুলো Git‑এ রাখুন (স্নিপেট/ইনক্লুড সহ)
• CI/CD দিয়ে পরিবর্তন রোলআউট করুন ড্রাই‑রান ভ্যালিডেশন স্টেপ দিয়ে
• একটি পরিচিত‑ভালো সংস্করণ হাতে রাখুন যাতে রোলব্যাক একটি ডেপ্লয়/রিলোডের সঙ্গে সম্পন্ন হয়

প্রোডাকশনে ডেপ্লয় করা: সাধারণ সেটআপ

প্রোডাকশন সেটআপগুলো কয়েকটি প্যাটার্নে মিলিত হয়, Nginx হন বা Caddy—সর্বোচ্চ পার্থক্য ডিফল্টে (Caddy‑র অটোম্যাটিক HTTPS) এবং আপনি কতটা স্পষ্ট কনফিগ পছন্দ করেন।

সার্ভিস হিসেবে চালানো (least privilege)

VM বা বেয়ার মেটালে উভয়ই সাধারণত systemd দিয়ে ম্যানেজ করা হয়। মূল হলো least privilege: সার্ভারটি ডেডিকেটেড, অপরিভিশড ইউজার হিসেবে চালান, কনফিগ ফাইল রুট‑ওন্ড করুন, এবং শুধুমাত্র প্রয়োজনীয় বইয়ের অনুমতি রাখুন।

Nginx‑এ সাধারণত রুট‑ওন্ড মাস্টার প্রসেস থাকে যা 80/443 বাইন্ড করে, এবং ওয়ার্কার প্রসেস www-data (অথবা অনুরূপ) হিসেবে চলে। Caddy‑তে সাধারণত একটি সার্ভিস অ্যাকাউন্ট থাকে এবং কম সক্ষমতা প্রদান করা হয় যা নিম্ন পোর্ট বাইন্ড করতে প্রয়োজন। উভয় ক্ষেত্রে TLS প্রাইভেট কী ও এনভায়রনমেন্ট ফাইল গোপন হিসেবে কঠোর অনুমতি দিন।

কন্টেইনার: কী পরিবর্তন হয়

কন্টেইনারে “সার্ভিস” নিজেই কন্টেইনার। সাধারণত:

• হোস্টে 80/443 এক্সপোজ করে কন্টেইনারে ম্যাপ করবেন
• কনফিগ ও সাইট ফাইল রিড‑ওনলি ভলিউম হিসেবে মাউন্ট করবেন
• সার্টিফিকেট কোথায় থাকবে তা নির্ধারণ করুন (Caddy: প্যার্সিস্টেন্ট ভলিউম; Nginx: আপনার সার্টি পাইপলাইন)

নেটওয়ার্কিং প্ল্যান করুন: রিভার্স প্রোক্সি আপনার অ্যাপ কন্টেইনারগুলোর একই Docker নেটওয়ার্কে থাকা উচিত, সার্ভিস নাম ব্যবহার করে হার্ড‑কোডেড IP এর পরিবর্তে।

একাধিক এনভায়রনমেন্ট ও জিরো‑ডাউনটাইম ডেপ্লয়

ভিন্ন কনফিগ (dev/stage/prod) বা টেমপ্লেটেড ভ্যারিয়েবল রাখুন যাতে আপনি "in-place" এডিট না করেন। জিরো‑ডাউনটাইম ডেপ্লয় প্যাটার্নগুলো:

• রোলিং আপডেট (Kubernetes/Swarm): ধীরে ধীরে ইনস্ট্যান্স বদলানো
• ব্লু/গ্রীন: নিয়ন্ত্রিত এক ধাপে ট্রাফিক স্যুইচ করা
• রিলোড‑ইন‑প্লেস: কনফিগ আপডেট করে গ্রেসফুল রিলোড যাতে বিদ্যমান কানেকশন শেষ হতে পারে

উভয় সার্ভার সেফ রিলোড সমর্থন করে; হেলথ চেক জুড়ে দিন যাতে কেবল স্বাস্থবান ব্যাকএন্ড ট্র্যাফিক পায়।

ব্যবহার কেস ও কোন সার্ভার কোথায় সেরা

Nginx ও Caddy‑এর মধ্যে বেছে নেওয়া কেবল “কে ভালো” নয়—এটি কি আপনি বিশ্বস্তভাবে ডেলিভার করতে চান এবং কে অপারেট করবে তার উপর নির্ভর করে।

সহজ ব্যক্তিগত সাইট, মিনিটে HTTPS

ব্লগ, পোর্টফোলিও, বা ডকস দ্রুত অনলাইনে আনতে চাইলে Caddy সাধারণত সহজতম বিজয়। একটি ন্যূনতম Caddyfile একটি ডিরেক্টরি সার্ভ করতে পারে এবং বাস্তব ডোমেইনের জন্য অটোম্যাটিক HTTPS সক্রিয় করে খুব কম নিয়মে। এতে সেটআপ সময় এবং বোঝার উপাদান কমে যায়।

ছোট ব্যবসার সাইট, রিডাইরেক্ট ও ক্যাশিং

উভয়ই এখানে ভাল; সিদ্ধান্ত অনেক সময় নির্ভর করে কে রক্ষণাবেক্ষণ করবে।

• Caddy ভালো যখন আপনি পরিষ্কার, পাঠযোগ্য রিডাইরেক্ট, ক্যাননিক্যাল ডোমেইন, এবং বেসিক ক্যাশিং হেডার চান।
• Nginx ভালো যদি আপনার হোস্টিং প্রোভাইডারের “স্ট্যান্ডার্ড Nginx কনফিগ” অনুসরণ করতে হয়, খুব নির্দিষ্ট ক্যাশিং প্রয়োজন, বা আপনার টিম ইতিমধ্যে বিদ্যমান সেটআপ জানে।

API + ওয়েব অ্যাপ রিভার্স প্রোক্সির পিছনে

একটি সাধারণ “ফ্রন্টেন্ড + API” ডেপ্লয়মেন্টের জন্য উভয় সার্ভার TLS টার্মিনেট করে অ্যাপ সার্ভারে প্রোক্সি করতে পারে।

• Nginx নিন যদি আপনি পরিণত, বহুল পরিচিত প্যাটার্নে নির্ভর করতে চান—লম্বা‑সময়ের ট্রাবলশুটিং ও টিউনিং সহ বড় টিমে সুবিধা।
• Caddy নিন যদি আপনি সরল কনফিগ চান এবং স্বয়ংক্রিয় সার্টিফিকেট হ্যান্ডলিং চান, এবং আপনার প্রোক্সি চাহিদা সরল।

বহু‑টেন্যান্ট সার্ভার অনেক ডোমেইন নিয়ে

এখানেই ট্রেড‑অফ স্পষ্ট হয়:

• Caddy জ্বলে যখন অনেক ডোমেইন হোস্ট করতে হয় এবং আপনি চাইবেন HTTPS অটোমেটিকভাবে হ্যান্ডেল করতে—প্রতি‑সাইট কনফিগ কম প্রয়োজন।
• Nginx শক্তিশালী যখন টেন্যানসি বাউন্ডারি জটিল (ভিন্ন টিম, কাস্টম রাউটিং, কড়া রিসোর্স কন্ট্রোল), অথবা আপনি সূক্ষ্ম নিয়ন্ত্রণ চান যা দীর্ঘদিন ধরে টিউন করা হয়েছে।

অজ্ঞাত হলে, Caddy‑কে দ্রুততা ও সরলতার জন্য বেছে নিন, এবং Nginx‑কে প্রতিষ্ঠিত প্রোডাকশনে সর্বোচ্চ পূর্বানুমানযোগ্যতার জন্য।

দ্রুত নোট টিমদের জন্য যারা দ্রুত অ্যাপ শিপ করে

আপনি যদি বড় চ্যালেঞ্জ অ্যাপ আউট করার হয়ে থাকে (শুধু প্রোক্সি বাছাই নয়), তাহলে বিল্ড ও ডেপ্লয়ের মধ্যে লুপ সংকীর্ণ করুন। উদাহরণস্বরূপ, Koder.ai আপনাকে চ্যাট ইন্টারফেস থেকে ওয়েব, ব্যাকএন্ড, ও মোবাইল অ্যাপ তৈরি করতে দেয় (React, Go + PostgreSQL, Flutter), তারপর সোর্স এক্সপোর্ট করে Caddy বা Nginx‑এর সামনে ডেপ্লয় করতে পারে। বাস্তবে, এর ফলে আপনি দ্রুত ইটারেট করতে পারেন এবং প্রোডাকশনে এখনও একটি প্রচলিত, অডিটযোগ্য এজ লেয়ার রাখতে পারেন।

মাইগ্রেশন নির্দেশিকা: Nginx ↔ Caddy স্থানান্তর

Nginx থেকে Caddy বা উল্টোদিকে মাইগ্রেশন সাধারণত “সব কিছু পুনরায় লেখার” চেয়ে কিছু মূল আচরণ অনুবাদ করার মতো: রাউটিং, হেডারস, TLS, এবং কিভাবে আপনার অ্যাপ ক্লায়েন্ট বিবরণ দেখছে।

Nginx থেকে Caddy‑তে স্যুইচ করলে কখন সুবিধা

Caddy নিন যখন আপনি সরল কনফিগ চান, অটোম্যাটিক HTTPS (নবায়ন সহ), এবং দিন‑দুই অপারেশনে কম অংশ চান। ছোট টিম, অনেক ছোট সাইট, এবং এমন প্রকল্প যেখানে আপনি ইরাডেক্টিভ ভাবে বলতে চান ("প্রোক্সি কর"/"সর্ব কর")—এগুলোতে Caddy ভাল।

Nginx‑এ থাকা নিরাপদ কেনা উচিত যখন

Nginx এ থাকুন যদি আপনি অতিরিক্ত কাস্টম সেটআপে নির্ভর করেন (অ্যাডভান্সড ক্যাশিং, জটিল রিরাইট, কাস্টম মডিউল), আপনি ইতিমধ্যে Nginx‑এ স্ট্যান্ডার্ডাইজড বা আপনার টিম বছরের পর বছর টিউন করা আচরণ প্রয়োজন।

মাইগ্রেশন ধাপ (অসুবিধা এড়াতে)

ইনভেন্টরি দিয়ে শুরু করুন: সব server blocks/সাইটগুলো তালিকা করুন, আপস্ট্রিম, TLS টার্মিনেশন পয়েন্ট, রিডাইরেক্ট, কাস্টম হেডার, রেট লিমিট, এবং স্পেশাল লোকেশন (যেমন /api, /assets)। তারপর:

1. একটি স্টেজিং কনফিগ বানান যা এক সাইট end‑to‑end মিলায়।
2. বাস্তব ট্রাফিক প্যাটার্ন দিয়ে যাচাই করুন (smoke tests + কিছু প্রোডাকশন‑ক্লাইক ফ্লো)।
3. স্টেজড রোলআউট করুন (এক হোস্ট, এক পাথ, অথবা LB দিয়ে ছোট শতাংশ)।
4. রোলব্যাক প্ল্যান তৈরি করুন: পুরানো কনফিগ অক্ষুণ্ণ রাখুন এবং DNS/LB ফ্লিপ রিভার্সিবল রাখুন।

সাধারণ মাইগ্রেশন গটচাস

হেডার পার্থক্য লক্ষ্য করুন (Host, X-Forwarded-For, X-Forwarded-Proto), websocket প্রোক্সি, রিডাইরেক্ট সেমান্টিকস (ট্রেইলিং স্ল্যাশ ও 301 বনাম 302), এবং পাথ হ্যান্ডলিং (Nginx location মিলন বনাম Caddy matchers)। এছাড়াও নিশ্চিত করুন আপনার অ্যাপ প্রক্সি হেডারগুলোকে ট্রাস্ট করে যাতে ভুল স্কীম/URL উৎপন্ন না করে।

সিদ্ধান্ত কাঠামো ও চূড়ান্ত সুপারিশ

Nginx ও Caddy‑এর মধ্যে বেছে নেওয়া দিনের এক বনাম দীর্ঘমেয়াদে আপনি কতটা নিয়ন্ত্রণ চান—এই কথাটাই বেশি গুরুত্বপূর্ণ। উভয়ই ওয়েবসাইট পরিবেশন ও অ্যাপ প্রোক্সি করতে সক্ষম; “সেরা” বেছে নেওয়া সাধারণত সেইটা যেটা আপনার টিমের দক্ষতা ও অপারেশনাল আরামে মিলে।

ব্যবহারিক সিদ্ধান্ত চেকলিস্ট

এই দ্রুত চেকলিস্ট দিয়ে সিদ্ধান্তকে যুক্তিসংগত রাখুন:

• দক্ষতা ও পরিচিতি: আপনারা কি পূর্বেই Nginx কনফিগ প্যাটার্ন জানেন?
• প্রথম কাজ করা HTTPS‑এ সময়: আপনি কি TLS অটোমেটিক চান নাকি নিজে যুক্ত করতে প্রস্তুত?
• শীঘ্রই দরকারি ফিচার: রেট লিমিটিং, ক্যাশিং, অ্যাডভান্সড রাউটিং, অথ, হেডার শেইপিং, অবজার্ভেবিলিটি।
• ঝুঁকি সহনশীলতা: কম অংশ vs গভীর কনফিগারেবিলিটি; “এখন সহজ” বনাম “স্কেলে পূর্বানুমানযোগ্য”।
• চেঞ্জ ম্যানেজমেন্ট: সেফ রিলোড, কনফিগ লিন্টিং, ও দুর্ঘটনায় ডাউনটাইম এড়ানো কত গুরুত্বপূর্ণ?

দ্রুত সুপারিশ (সাধারণ দৃশ্যপট)

• একক অ্যাপ + কাস্টম ডোমেইন + দ্রুত HTTPS চান: Caddy প্রায়শই সহজ শুরু, বিশেষ করে ছোট ডেপ্লয়মেন্টে।
• আপনি ইতিমধ্যে Nginx চালান (বা শেয়ার্ড স্নিপেট আছে): Nginx‑এ থাকা আশঙ্কা ও ট্রেনিং খরচ কমায়।
• উচ্চ‑ট্রাফিক প্রোক্সি ও সূক্ষ্ম টিউনিং দরকার: Nginx প্রায়ই চয়ন করা হয় যখন আপনি কাশিং, বাফারিং, ও এজ আচরণে এক্সটেনসিভ কন্ট্রোল চান।
• ছোট টিম, অনেক সার্ভিস, পড়তে সহজ কনফিগ পছন্দ: Caddy‑তে অডিট ও ইটারেশন সহজ।

পক্ষে/বিপক্ষে সংক্ষেপ (কোনোটাই চূড়ান্ত নয়)

Caddy সাধারণত দেয়: সরল কনফিগ, স্বয়ংক্রিয় HTTPS ফ্লো, ও বন্ধুত্বপূর্ণ প্রথম‑দিন অভিজ্ঞতা।

Nginx সাধারণত দেয়: প্রোডাকশনে দীর্ঘ ট্র্যাক রেকর্ড, বিস্তৃত কমিউনিটি জ্ঞাণ, এবং বিশেষায়িত সেটআপের জন্য বহু নবলস।

আরও শেখার স্থান

• Caddy ডকুমেন্টেশন ও কমিউনিটি: /resources/caddy-docs, /resources/caddy-community
• Nginx ডকুমেন্টেশন ও কমিউনিটি: /resources/nginx-docs, /resources/nginx-community

যদি আপনি এখনও অনির্ণীত হন, সেইটা বেছে নিন যা আপনি রাত ২টার সময় আত্মবিশ্বাস নিয়ে অপারেট করতে পারবেন—এবং আপনার প্রয়োজন (ট্রাফিক, টিম, কমপ্লায়েন্স) স্পষ্ট হলে পুনরায় মূল্যায়ন করুন।