Nginx সার্ভার ব্লক (ভার্চুয়াল হোস্ট) দিয়ে একাধিক সাইট হোস্টিং

Nginx সার্ভার ব্লক হল ভার্চুয়াল হোস্ট ধারণা যা আপনাকে একটি Nginx ইনস্টলেশনে একাধিক ডোমেন বা ওয়েবসাইটকে আলাদা কনফিগারেশনের মাধ্যমে প্রকাশ করতে দেয়। উদাহরণস্বরূপ, আপনি একই VPS-তে example.com, blog.example.com এবং second-site.com এর জন্য আলাদা রুট ডিরেক্টরি, লগ ফাইল, SSL সার্টিফিকেট এবং PHP সেটিংস নির্ধারণ করতে পারেন। সংক্ষেপে সমাধান হল; প্রতিটি সাইটের জন্য আলাদা ডিরেক্টরি তৈরি করা, ডোমেনের DNS রেকর্ডগুলো সার্ভারের IP ঠিকানার দিকে নির্দেশ করা, /etc/nginx/sites-available-এর অধীনে আলাদা একটি সার্ভার ব্লক লেখা, এটিকে sites-enabled ডিরেক্টরিতে সংযুক্ত করা, কনফিগারেশনটি পরীক্ষা করা এবং Nginx পরিষেবাটি আবার লোড করা।

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

Nginx সার্ভার ব্লক কী?

Nginx সার্ভার ব্লক হল Nginx কনফিগারেশনের মধ্যে সার্ভার ব্লক হিসাবে সংজ্ঞায়িত অংশ যা incoming HTTP বা HTTPS অনুরোধ কোন সাইটের দিকে পরিচালিত হবে তা নির্ধারণ করে। এটি Apache-এর VirtualHost ধারণার সাথে অনুরূপ। যখন একজন দর্শক ব্রাউজারে একটি ডোমেন নাম লিখে, DNS সেই ডোমেন নামটি সার্ভারের IP ঠিকানায় রূপান্তর করে। তারপর Nginx আসা Host হেডারের দিকে দেখে এবং server_name মানের সাথে মেলে এমন সার্ভার ব্লকটি কার্যকর করে।

এভাবে একই IP ঠিকানা এবং একই শারীরিক বা ভার্চুয়াল সার্ভারের উপর শতাধিক ভিন্ন ওয়েবসাইট প্রকাশ করা যায়। প্রতিটি সাইটের জন্য আলাদা রুট ডিরেক্টরি, অ্যাক্সেস লগ, ত্রুটি লগ, রিডাইরেকশন নিয়ম, SSL সার্টিফিকেট, ক্যাশে নীতি এবং সুরক্ষা নিয়ম নির্ধারণ করা সম্ভব। উদাহরণস্বরূপ, আপনার কর্পোরেট সাইটটি /var/www/corporate/public-এ, আপনার ব্লগটি /var/www/blog/public-এ এবং আপনার টেস্ট পরিবেশটি /var/www/staging/public-এ রাখতে পারেন।

Nginx এই কাঠামোতে অত্যন্ত কার্যকরী কারণ এটি ইভেন্ট-চালিত স্থাপনার কারণে উচ্চ সমান্তরাল সংযোগগুলিকে কম রিসোর্স ব্যবহারের মাধ্যমে পরিচালনা করতে পারে। এই কারণে এটি শেয়ারড হোস্টিং, VPS, ক্লাউড সার্ভার এবং উচ্চ ট্রাফিক অ্যাপ্লিকেশন অবকাঠামোর মধ্যে প্রচুর ব্যবহৃত হয়। একাধিক সাইট হোস্টিংয়ের সঠিক কাজের জন্য ফাইল অনুমতি থেকে DNS রিডাইরেকশন, SSL সেটআপ থেকে লগ বিভাজন পর্যন্ত প্রতিটি বিবরণ সঠিক পরিকল্পনা করা প্রয়োজন।

Nginx সার্ভার ব্লক কখন ব্যবহার করা হয়?

Nginx সার্ভার ব্লকগুলো বিশেষ করে একক সার্ভারে একাধিক ওয়েব উপস্থিতি পরিচালনা করতে হলে ব্যবহার করা হয়। এটি কখনও দুটি ছোট কর্পোরেট সাইট হতে পারে, কখনও শতাধিক ক্লায়েন্ট প্রকল্প, সাবডোমেইন বা মাইক্রো সার্ভিস হতে পারে। এখানে গুরুত্বপূর্ণ বিষয় হল, প্রতিটি প্রকল্পের একটি অপরটির থেকে যৌক্তিকভাবে পৃথক করা।

• একাধিক ডোমেন একই VPS-এ প্রকাশ করতে চাইলে।
• www এবং www ছাড়া ডোমেনগুলোকে একটি ক্যানোনিক ঠিকানায় রিডাইরেক্ট করতে চাইলে।
• সাবডোমেইনগুলোকে আলাদা ফোল্ডার বা অ্যাপ্লিকেশনের সাথে সংযুক্ত করতে চাইলে।
• প্রতিটি সাইটের জন্য আলাদা SSL সার্টিফিকেট এবং নিরাপত্তা নীতি নির্ধারণ করতে চাইলে।
• ক্লায়েন্ট প্রকল্পগুলোকে আলাদা লগ ফাইলে ট্র্যাক করতে চাইলে।
• Laravel, WordPress, স্ট্যাটিক HTML এবং Node.js-এর মতো ভিন্ন অ্যাপ্লিকেশনগুলোকে একই সার্ভারে চালাতে চাইলে।

উদাহরণস্বরূপ, একটি ডিজিটাল এজেন্সি যদি একটি 4 GB RAM VPS-এ 8টি কম ট্রাফিক কর্পোরেট সাইট প্রকাশ করে তবে এটি প্রযুক্তিগতভাবে সম্ভব। তবে প্রতিটি সাইটের জন্য ট্রাফিক, ডিস্ক ব্যবহার, PHP প্রসেস সংখ্যা, ডেটাবেস লোড এবং ব্যাকআপ ফ্রিকোয়েন্সি হিসাব করা উচিত। যদি প্রকল্পগুলো উচ্চ ট্রাফিক পায় বা রিসোর্স বিচ্ছিন্নতা গুরুত্বপূর্ণ হয় তবে আরও শক্তিশালী VPS, ক্লাউড সার্ভার বা ম্যানেজেবল হোস্টিং সমাধানগুলি নির্বাচন করা উচিত। এই পর্যায়ে ওয়েব হোস্টিং এবং কর্পোরেট হোস্টিং বিকল্পগুলি তুলনা করা যেতে পারে।

শুরু করার আগে প্রয়োজনীয়তা

এই গাইডে আমরা Ubuntu বা Debian ভিত্তিক একটি লিনাক্স সার্ভার অনুমান করব। কমান্ডগুলো বিতরণের উপর নির্ভর করে কিছুটা ভিন্ন হতে পারে; তবে যুক্তি একই। উৎপাদন পরিবেশে কাজ করার আগে অবশ্যই ব্যাকআপ নিতে হবে। একটি ভুল Nginx কনফিগারেশন সমস্ত সাইটগুলিকে অস্থায়ীভাবে অপ্রাপ্য করে দিতে পারে।

প্রয়োজনীয় প্রযুক্তিগত প্রস্তুতি

• Root বা sudo অধিকারযুক্ত Linux ব্যবহারকারী অ্যাকাউন্ট।
• স্থাপিত এবং চলমান Nginx পরিষেবা।
• সার্ভারের IP ঠিকানায় নির্দেশিত অন্তত একটি ডোমেন নাম।
• 80 এবং 443 পোর্টগুলোর জন্য ফায়ারওয়ালে উন্মুক্ত থাকা।
• সাইটের ফাইলগুলোর জন্য একটি নিয়মিত ডিরেক্টরি কাঠামো।
• SSL-এর জন্য একটি বৈধ সার্টিফিকেট বা বিনামূল্যে Let’s Encrypt ব্যবহার।
• PHP ভিত্তিক অ্যাপ্লিকেশনের জন্য PHP-FPM ইনস্টলেশন।

DNS পক্ষে A রেকর্ড প্রধান ডোমেন নামকে IPv4 ঠিকানায়, AAAA রেকর্ড থাকলে IPv6 ঠিকানায় নির্দেশ করে। www-এর মতো সাবডোমেইনের জন্য CNAME বা A রেকর্ড ব্যবহার করা যেতে পারে। DNS প্রচার সাধারণত কয়েক মিনিট থেকে 24 ঘন্টার মধ্যে সম্পন্ন হয়। নতুন ইনস্টলেশনের সময় DNS রেকর্ড প্রস্তুত করার পরে Nginx সার্ভার ব্লক কনফিগারেশনে চলে যাওয়া প্রক্রিয়াটি দ্রুততর করে।

প্রস্তাবিত ডিরেক্টরি কাঠামো

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

একটি উদাহরণ কাঠামো এইভাবে পরিকল্পনা করা যেতে পারে: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public এবং /var/www/site2.com/logs। Nginx রুট মান সরাসরি পাবলিক ডিরেক্টরির দিকে নির্দেশ করা উচিত। এর ফলে অ্যাপ্লিকেশন ফাইল, .env এর মতো সংবেদনশীল ফাইল এবং ব্যাকআপগুলি ওয়েবের মাধ্যমে সরাসরি অ্যাক্সেসযোগ্য হবে না।

উদাহরণ স্ট্যাটিক টেস্ট পৃষ্ঠার জন্য প্রতিটি সাইট ফোল্ডারে একটি সাধারণ index.html ফাইল রাখতে পারেন। এর মধ্যে সাইটের নাম লিখে কোন সার্ভার ব্লকটি কাজ করছে তা দ্রুত যাচাই করতে পারবেন। উৎপাদন পরিবেশে এই ফোল্ডারগুলোর মালিকানা সাধারণত www-data ব্যবহারকারী বা ডেপ্লয়মেন্ট করা বিশেষ ব্যবহারকারীর মাধ্যমে নিয়ন্ত্রিত হয়। ফাইল অনুমতিতে ফোল্ডারের জন্য 755, ফাইলের জন্য 644 বেশিরভাগ স্ট্যাটিক দৃশ্যে যথেষ্ট। WordPress-এর মতো লেখার প্রয়োজনীয় অ্যাপ্লিকেশনগুলির জন্য uploads ডিরেক্টরির মতো ক্ষেত্রগুলো আলাদাভাবে মূল্যায়ন করা উচিত।

ধাপে ধাপে Nginx সার্ভার ব্লক তৈরি করা

নিচের পদক্ষেপগুলি উদাহরণস্বরূপ site1.com ডোমেন নামের মাধ্যমে বর্ণনা করা হয়েছে। একই পদ্ধতি দ্বিতীয়, তৃতীয় বা আরও সাইটের জন্য পুনরাবৃত্তি করতে পারেন। গুরুত্বপূর্ণ বিষয় হল প্রতিটি সাইটের জন্য অনন্য server_name, root এবং লগ ফাইল ব্যবহার করা।

1. সাইটের ফোল্ডার তৈরি করুন

প্রথম পদক্ষেপ হল ওয়েব ফাইলগুলোর জন্য ডিরেক্টরি তৈরি করা। উদাহরণ: sudo mkdir -p /var/www/site1.com/public। তারপর পরীক্ষার জন্য /var/www/site1.com/public/index.html ফাইল তৈরি করে এর মধ্যে "এটি site1.com টেস্ট পৃষ্ঠা" এর মতো একটি স্বতন্ত্র টেক্সট লিখতে পারেন।

ফাইলের মালিকানা সঠিকভাবে সেট করার জন্য sudo chown -R www-data:www-data /var/www/site1.com কমান্ড ব্যবহার করা যেতে পারে। যদি আপনি ডেপ্লয়মেন্টের কাজগুলি ভিন্ন ব্যবহারকারীর মাধ্যমে করেন তবে গ্রুপ অনুমতিগুলো সেই অনুযায়ী সংশোধন করুন। উৎপাদন পরিবেশে সকলের জন্য লেখার অনুমতি 777-এর মতো অনুমতিগুলো এড়িয়ে চলুন। এই অনুমতিগুলো আক্রমণকারীদের আপলোড ডিরেক্টরিগুলোকে অপব্যবহার করতে পারে।

2. সার্ভার ব্লক ফাইল তৈরি করুন

Nginx-এ একটি সাধারণ অভ্যাস হল নিষ্ক্রিয় কনফিগারেশনগুলোকে /etc/nginx/sites-available অধীনে রাখা এবং সক্রিয় করতে /etc/nginx/sites-enabled-এ একটি প্রতীকী লিঙ্ক তৈরি করা। উদাহরণ ফাইল: /etc/nginx/sites-available/site1.com।

একটি সাধারণ HTTP সার্ভার ব্লক এইভাবে লেখা হয়: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

এই কনফিগারেশনে listen 80 HTTP ট্রাফিককে শোনে, server_name কোন ডোমেনগুলো এই ব্লকের আওতাধীন তা নির্দেশ করে, root ওয়েব ফাইলগুলোর অবস্থান নির্দিষ্ট করে, index ডিফল্ট ফাইলকে সংজ্ঞায়িত করে। try_files অনুরোধকৃত ফাইল বা ফোল্ডারটি খুঁজে না পেলে 404 ফেরত দেয়। স্ট্যাটিক সাইটের জন্য এই কাঠামো অত্যন্ত কার্যকর।

3. সাইটটি সক্রিয় করুন

কনফিগারেশনটি সক্রিয় করতে একটি প্রতীকী লিঙ্ক তৈরি করা হয়: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com। এই পদ্ধতি ফাইলগুলো কপি করার চেয়ে স্বাস্থ্যকর কারণ আপনি একটি প্রধান কনফিগারেশন ফাইলের উপরে কাজ করেন। পরিবর্তন করলে সংযুক্ত ফাইলও আপডেট থাকে।

যদি আপনি চান না যে ডিফল্ট Nginx পৃষ্ঠা আপনার সাইটের সামনে আসুক, তবে ডিফল্ট কনফিগারেশনটি নিষ্ক্রিয় করতে পারেন। এর জন্য /etc/nginx/sites-enabled/default লিঙ্কটি সরিয়ে ফেলা যেতে পারে। তবে এটি করার আগে আপনার নিজের সার্ভার ব্লকটি সঠিকভাবে কাজ করছে কিনা তা নিশ্চিত করুন।

4. কনফিগারেশন পরীক্ষা করুন এবং Nginx পুনরায় লোড করুন

প্রতিটি পরিবর্তনের পরে sudo nginx -t কমান্ডের মাধ্যমে সিনট্যাক্স পরীক্ষা করা উচিত। পরীক্ষা সফল হলে sudo systemctl reload nginx কমান্ডের মাধ্যমে পরিষেবাটি ক্রমাগতভাবে পুনরায় লোড করা হয়। reload কমান্ড সাধারণত restart কমান্ডের তুলনায় বেশি নিরাপদ কারণ এটি চলমান সংযোগগুলোকে আরও মসৃণভাবে পরিচালনা করে।

যদি পরীক্ষা ব্যর্থ হয় তবে ত্রুটি বার্তাটি সাধারণত ফাইলের নাম এবং সারণী নম্বরটি দেখায়। অনুপস্থিত সেমিকোলন, ভুল বন্ধনীর কাঠামো, ভুল ডিরেক্টরি পথ বা সংঘর্ষকারী server_name মানগুলিই সবচেয়ে সাধারণ সমস্যা। ত্রুটি সমাধান না হওয়া পর্যন্ত Nginx পুনরায় লোড করা উচিত নয়।

দ্বিতীয় এবং তৃতীয় সাইট যুক্ত করা

একাধিক সাইট হোস্টিংয়ের সুবিধা হল প্রথম সঠিক ইনস্টলেশনের পরে প্রক্রিয়াটি পুনরাবৃত্তিযোগ্য হয়ে উঠছে। site2.com এর জন্য /var/www/site2.com/public ডিরেক্টরি তৈরি করুন, /etc/nginx/sites-available/site2.com ফাইলটি লিখুন, root এবং লগ মানগুলি site2.com-এ পরিবর্তন করুন, প্রতীকী লিঙ্ক তৈরি করুন এবং Nginx পরীক্ষাটি চালান।

দ্বিতীয় সাইটের জন্য সাধারণ কাঠামো এইভাবে আলাদা হয়: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

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

SSL এবং HTTPS কনফিগারেশন

2026 সালের SEO মান অনুযায়ী HTTPS এখন শুধুমাত্র একটি সুরক্ষা বৈশিষ্ট্য নয়, বরং ব্যবহারকারীর বিশ্বাস এবং প্রযুক্তিগত গুণমানের একটি সূচক। ব্রাউজারগুলি HTTP সাইটগুলোকে অসুরক্ষিত হিসেবে চিহ্নিত করে; অর্থ, সদস্যপদ, ফর্ম বা অ্যাডমিন প্যানেল অন্তর্ভুক্ত প্রকল্পগুলোর জন্য SSL অপরিহার্য। একাধিক সাইট হোস্টিংয়ের সময় প্রতিটি ডোমেনের জন্য সঠিক সার্টিফিকেট সংজ্ঞায়িত করা উচিত। Hostragons-এর মাধ্যমে SSL প্রয়োজনের জন্য এসএসএল সার্টিফিকেট পৃষ্ঠাটি দেখুন।

যদি আপনি Let’s Encrypt ব্যবহার করেন তবে Certbot-এর মাধ্যমে প্রতিটি ডোমেনের জন্য সার্টিফিকেট পাওয়া যায়। উদাহরণ প্রক্রিয়ায় certbot --nginx -d site1.com -d www.site1.com কমান্ডটি Nginx কনফিগারেশনটি সনাক্ত করে এবং HTTPS ব্লকটি স্বয়ংক্রিয়ভাবে যুক্ত করতে পারে। তবে স্বয়ংক্রিয় সম্পাদনার পরে ফাইলটি পরীক্ষা করা একটি ভাল অভ্যাস। ভুল রিডাইরেকশন বা পুনরাবৃত্ত সার্ভার ব্লক সমস্যা ঘটতে পারে।

HTTPS কনফিগারেশনে সাধারণত 80 পোর্টের ট্রাফিক 443 পোর্টে স্থায়ীভাবে রিডাইরেক্ট করা হয়। 301 রিডাইরেকশন SEO দৃষ্টিকোণ থেকে স্থায়ী পছন্দের সংকেত দেয়। আপনি www ব্যবহার করবেন কিনা তা নির্ধারণ করুন এবং সমস্ত ভেরিয়েশনগুলোকে একটি ক্যানোনিক ঠিকানায় একত্রিত করুন। উদাহরণস্বরূপ https://www.site1.com এর পরিবর্তে https://site1.com ব্যবহার করতে চাইলে, HTTP এবং HTTPS উভয় www ট্রাফিককে www ছাড়া ঠিকানায় রিডাইরেক্ট করুন। এটি কপি কনটেন্টের ঝুঁকি কমায়।

PHP এবং WordPress সাইটের জন্য Nginx সার্ভার ব্লক

স্ট্যাটিক HTML সাইটগুলোর কনফিগারেশন সহজ; তবে WordPress, Laravel বা কাস্টম PHP অ্যাপ্লিকেশনগুলিতে PHP-FPM-এর সাথে একত্রিতকরণ প্রয়োজন। এই ক্ষেত্রে index.php ফাইলটি সংজ্ঞায়িত করা হয় এবং PHP অনুরোধগুলি সংশ্লিষ্ট সকেটে রিডাইরেক্ট করা হয়। উদাহরণস্বরূপ, Ubuntu-তে PHP 8.3 এর জন্য সকেটের পথ /run/php/php8.3-fpm.sock হতে পারে। সংস্করণ সার্ভারের উপর নির্ভর করে পরিবর্তিত হয়।

PHP ভিত্তিক উদাহরণ কাঠামো: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

WordPress-এর জন্য স্থায়ী লিঙ্কগুলো কাজ করার জন্য try_files $uri $uri/ /index.php?$args কাঠামোটি গুরুত্বপূর্ণ। এছাড়াও xmlrpc.php অ্যাক্সেস, wp-login.php রেট লিমিটেশন, uploads ডিরেক্টরিতে PHP চালানোর নিষেধাজ্ঞা ইত্যাদি নিরাপত্তা ব্যবস্থা বিবেচনায় নেওয়া উচিত। যদি আপনি একই VPS-এ অনেক WordPress সাইট হোস্ট করেন তবে প্রতিটি সাইটের জন্য আলাদা ডেটাবেস, আলাদা ব্যবহারকারী এবং নিয়মিত আপডেট নীতি ব্যবহার করুন। WordPress হোস্টিং বিকল্প খুঁজছেনদের জন্য WordPress হোস্টিং একটি আরও পরিচালনাযোগ্য বিকল্প হতে পারে।

Nginx সার্ভার ব্লক এবং Apache VirtualHost-এর তুলনা

Nginx এবং Apache একই লক্ষ্য অর্জনের জন্য ভিন্ন স্থাপনা ব্যবহার করে। উভয়ই একটি সার্ভারে একাধিক সাইট হোস্ট করতে পারে। নির্বাচনটি অ্যাপ্লিকেশন প্রয়োজনীয়তা, পরিচালনার অভ্যাস এবং কর্মক্ষমতা প্রত্যাশার উপর নির্ভর করে।

যদি আপনার অ্যাপ্লিকেশন .htaccess নিয়মগুলির প্রতি গভীরভাবে নির্ভরশীল হয় তবে Apache ব্যবহার করা সহজ হতে পারে। তবে উচ্চ ট্রাফিক, রিভার্স প্রক্সি, ক্যাশে এবং আধুনিক বিতরণ প্রবাহের জন্য Nginx বেশিরভাগ প্রকল্পে শক্তিশালী একটি পছন্দ। কিছু অবকাঠামোতে Nginx রিভার্স প্রক্সি, Apache হল ব্যাকএন্ড অ্যাপ্লিকেশন সার্ভার হিসাবে একত্রে ব্যবহার করা হতে পারে।

নিরাপত্তার জন্য সেরা অনুশীলন

একই সার্ভারে একাধিক সাইট হোস্টিং খরচের ক্ষেত্রে সুবিধা দেয়; তবে নিরাপত্তার দায়িত্ব বাড়িয়ে দেয়। এক সাইটের দুর্বলতা অন্যগুলোর উপর প্রভাব ফেলতে না পারে সেজন্য বিচ্ছিন্নতা এবং সর্বনিম্ন অনুমতি নীতি প্রয়োগ করা উচিত।

• প্রতিটি সাইটের জন্য আলাদা ডেটাবেস এবং আলাদা ডেটাবেস ব্যবহারকারী তৈরি করুন।
• ওয়েব রুট ডিরেক্টরিকে শুধুমাত্র পাবলিক ফোল্ডারের সাথে সীমাবদ্ধ করুন।
• ব্যাকআপ, .env, .git, কনফিগ এবং SQL ফাইলগুলোকে ওয়েব অ্যাক্সেসের বাইরে রাখুন।
• SSL সার্টিফিকেটগুলো নিয়মিত নবীকরণ করুন এবং HTTPS রিডাইরেকশনকে বাধ্যতামূলক করুন।
• সার্ভারে UFW বা অনুরূপ নিরাপত্তা ফায়ারওয়াল ব্যবহার করুন; শুধুমাত্র প্রয়োজনীয় পোর্টগুলো খুলুন।
• Nginx এবং অপারেটিং সিস্টেমের আপডেটগুলো নিয়মিতভাবে প্রয়োগ করুন।
• প্রতিটি সাইটের জন্য আলাদা access_log এবং error_log রাখুন।
• অ্যাডমিন প্যানেলগুলোর জন্য IP সীমাবদ্ধতা অথবা অতিরিক্ত প্রমাণীকরণ যোগ করুন।
• ফাইলের অনুমতিতে 777-এর মতো ব্যাপক অনুমতি এড়িয়ে চলুন।

এছাড়াও মৌলিক নিরাপত্তা শিরোনাম যোগ করা উপকারী। X-Frame-Options, X-Content-Type-Options, Referrer-Policy এবং Content-Security-Policy এর মতো শিরোনাম উপযুক্ত প্রকল্পে মূল্যায়ন করা যেতে পারে। তবে বিশেষ করে Content-Security-Policy ভুলভাবে প্রয়োগ করা হলে স্ক্রিপ্ট এবং স্টাইল ফাইলগুলিকে ব্লক করতে পারে; তাই এটি প্রথমে টেস্ট পরিবেশে পরীক্ষা করা উচিত। নিরাপত্তা সম্পর্কে আরও কনটেন্টের জন্য ওয়েবসাইট নিরাপত্তা নিবন্ধগুলোতে লিঙ্ক দেওয়া যেতে পারে।

কর্মক্ষমতা এবং SEO-এর জন্য নজর দেওয়া বিষয়

Nginx সার্ভার ব্লকগুলো শুধুমাত্র প্রকাশনা নয়, কর্মক্ষমতা এবং SEO গুণমানকেও প্রভাবিত করে। ভুল রিডাইরেকশন চেইন, ভুল ক্যানোনিকাল পছন্দ, অনুপস্থিত gzip বা brotli সংকোচন, বড় লগ ফাইল এবং অপর্যাপ্ত ক্যাশে সেটিংগুলি সাইটের গতিকে কমিয়ে দিতে পারে। Google-এর পৃষ্ঠা অভিজ্ঞতা সংকেতগুলি ব্যবহারকারী-কেন্দ্রিক; দ্রুত প্রতিক্রিয়া জানানো, নিরাপদ এবং স্থিতিশীল সাইটগুলো সাধারণত আরও ভালো কর্মক্ষমতা প্রদর্শন করে।

প্রথমে প্রতিটি ডোমেনের জন্য একটি ক্যানোনিক সংস্করণ নির্ধারণ করুন। HTTP থেকে HTTPS-এ, www থেকে www ছাড়া অথবা সম্পূর্ণ বিপরীতে একক পদক্ষেপে রিডাইরেক্ট করুন। চেইনটি এইভাবে হতে পারবে না: http://site.com প্রথমে http://www.site.com, তারপর https://www.site.com, তারপর https://site.com। পরিবর্তে একক 301-এর মাধ্যমে লক্ষ্যস্থলে যাওয়া অনেক বেশি সঠিক।

স্ট্যাটিক ফাইলগুলোর জন্য ক্যাশ-নিয়ন্ত্রণ শিরোনাম ব্যবহার করা যেতে পারে। চিত্র, CSS এবং JS ফাইলগুলোর নির্দিষ্ট সময় ব্রাউজারে সংরক্ষণ করা যেতে পারে। তবে বারবার পরিবর্তিত ফাইলগুলোর ক্ষেত্রে ফাইলের নাম সংস্করণিং অথবা কোয়েরি স্ট্রিং কৌশল ব্যবহার করা উচিত। gzip সংকোচন HTML, CSS, JS এবং JSON-এর মতো টেক্সট-ভিত্তিক ফাইলগুলোর ব্যান্ডউইথ কমিয়ে দেয়। উচ্চ ট্রাফিকের সাইটগুলোর জন্য Nginx মাইক্রোক্যাশ, FastCGI ক্যাশে অথবা CDN ব্যবহারের বিষয়টি বিবেচনা করা যেতে পারে। CDN এবং বৈশ্বিক অ্যাক্সেসের প্রয়োজনের জন্য CDN কি এর মতো একটি কনটেন্টে লিঙ্ক দেওয়া যেতে পারে।

লগ পরিচালনা এবং পর্যবেক্ষণ

একাধিক সাইট হোস্টিংয়ে লগ পরিচালনা সমস্যা সমাধানের চাবিকাঠি। আলাদা লগ ফাইলগুলো স্পষ্টভাবে দেখায় কোন সাইটে কোন ত্রুটি ঘটছে। access_log দর্শক অনুরোধগুলোকে রেকর্ড করে, error_log কনফিগারেশন, অনুমতি, ফাইল অনুপস্থিতি এবং আপস্ট্রিম ত্রুটিগুলোকে রেকর্ড করে। 502 Bad Gateway ত্রুটি সাধারণত PHP-FPM অথবা ব্যাকএন্ড পরিষেবা সংযোগের সাথে সম্পর্কিত। 403 Forbidden অনুমতি বা ইনডেক্স ফাইলের সমস্যা হতে পারে। 404 Not Found ফাইলের পথ, পুনঃলিখন অথবা DNS পরবর্তীকালের ভুল রুট সমস্যার দিকে নির্দেশ করতে পারে।

লগ ফাইলগুলোর সীমাহীন বৃদ্ধিকে প্রতিরোধ করতে logrotate কনফিগারেশনটি পরীক্ষা করা উচিত। ছোট প্রকল্পগুলোর জন্য দৈনিক অথবা সাপ্তাহিক রোটেশন যথেষ্ট হতে পারে। ট্রাফিকের উচ্চ সাইটগুলোর জন্য কেন্দ্রীয় লগ সংগ্রহ, মেট্রিক পর্যবেক্ষণ এবং সতর্কতা সিস্টেমগুলো ব্যবহার করা উচিত। ডিস্ক পূর্ণ হয়ে গেলে Nginx লগ লেখতে পারে না, ডেটাবেস বন্ধ হয়ে যায় এবং সাইটগুলো অপ্রাপ্য হয়ে যায়। তাই ডিস্ক ব্যবহারের জন্য থ্রেশহোল্ডগুলি নির্ধারণ করা একটি কার্যকরী প্রতিরোধ।

সাধারণ ত্রুটি এবং দ্রুত সমাধান

Nginx সার্ভার ব্লকগুলোর সাথে কাজ করার সময় কিছু ত্রুটি প্রায় প্রতিটি প্রকল্পে আপনার সামনে আসতে পারে। এগুলো জানা ইনস্টলেশন সময়কে উল্লেখযোগ্যভাবে কমিয়ে দেয়।

• ডোমেন নাম ভুল সাইট খুলছে: server_name সংঘর্ষ এবং ডিফল্ট সার্ভার ব্লক পরীক্ষা করুন।
• 403 Forbidden ত্রুটি: রুট ডিরেক্টরি, ফাইল অনুমতি এবং ইনডেক্স ফাইলের অস্তিত্ব পরীক্ষা করুন।
• 404 Not Found ত্রুটি: রুট পথ এবং try_files নিয়মটি পরীক্ষা করুন।
• 502 Bad Gateway ত্রুটি: PHP-FPM পরিষেবাটি চলমান এবং সকেটের পথটি সঠিক কিনা তা নিশ্চিত করুন।
• SSL সার্টিফিকেট ভুল সাইটের জন্য দেখাচ্ছে: 443 পোর্টের server_name এবং সার্টিফিকেট ফাইলগুলো পরীক্ষা করুন।
• রিডাইরেকশন চক্র ঘটছে: HTTP-HTTPS এবং www রিডাইরেকশন নিয়মগুলো সহজ করুন।
• Nginx পুনরায় লোড হচ্ছে না: sudo nginx -t আউটপুটের সারণী নম্বর অনুযায়ী সিনট্যাক্স ত্রুটিটি সংশোধন করুন।

অভিজ্ঞ অ্যাডমিনদের একটি সাধারণ চেকলিস্ট রয়েছে: DNS সঠিক কি, Nginx কনফিগারেশন কার্যকর কি, রুট ফোল্ডার আছে কি, অনুমতিগুলো সঠিক কি, পরিষেবাটি পরীক্ষায় উত্তীর্ণ হয়েছে কি, লগ কী বলছে? এই ক্রমে এগিয়ে যাওয়া প্যানিক ছাড়া দ্রুত সমাধান উৎপাদনে সহায়তা করে।

উৎপাদন পরিবেশের জন্য কার্যকরী চেকলিস্ট

লাইভে যাওয়ার আগে নিচের চেকলিস্টের মাধ্যমে প্রতিটি সাইট যাচাই করুন। বিশেষ করে ক্লায়েন্ট প্রকল্পগুলোর জন্য ডেলিভারির আগে এই বিষয়গুলো নথিবদ্ধ করা পেশাদার মানের একটি স্ট্যান্ডার্ড তৈরি করে।

• ডোমেন নাম A বা AAAA রেকর্ড সঠিক IP ঠিকানায় নির্দেশ করছে।
• www এবং www না হওয়া সংস্করণগুলোর মধ্যে একটি ক্যানোনিক্যালভাবে নির্বাচিত হয়েছে।
• HTTP ট্রাফিক 301 দিয়ে HTTPS-এ রিডাইরেক্ট হচ্ছে।
• SSL সার্টিফিকেট বৈধ এবং স্বয়ংক্রিয় নবীকরণ সক্রিয়।
• প্রতিটি সাইটের জন্য আলাদা রুট এবং লগ ফাইল নির্ধারণ করা হয়েছে।
• Nginx কনফিগারেশন sudo nginx -t দিয়ে যাচাই করা হয়েছে।
• ব্যাকআপ পরিকল্পনা নির্ধারণ করা হয়েছে এবং পুনরুদ্ধার পরীক্ষা করা হয়েছে।
• ফাইল অনুমতিগুলি সর্বনিম্ন অনুমতি নীতির সাথে সামঞ্জস্যপূর্ণ।
• ফায়ারওয়ালে শুধুমাত্র প্রয়োজনীয় পোর্ট উন্মুক্ত।
• ত্রুটি লগগুলি লাইভে যাওয়ার পর অন্তত 15 মিনিট পর্যবেক্ষণ করা হয়েছে।

এই তালিকা ছোট মনে হলেও বাস্তব প্রকল্পগুলোর ক্ষেত্রে বিঘ্নের ঝুঁকি উল্লেখযোগ্যভাবে কমিয়ে দেয়। বিশেষ করে SSL নবীকরণ, DNS পরীক্ষা এবং লগ পর্যবেক্ষণ পদক্ষেপগুলো বেশিরভাগ অদৃশ্য ত্রুটিগুলোকে আগে থেকেই ধরতে পারে।

ফলাফল

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

যদি আপনি একটি নতুন প্রকল্প প্রকাশ করতে যাচ্ছেন তবে প্রথমে আপনার ডোমেন নাম, সার্ভার রিসোর্স এবং SSL প্রয়োজনীয়তাগুলো স্পষ্ট করুন; তারপর উপরে উল্লেখিত চেকলিস্টের মাধ্যমে আপনার Nginx কনফিগারেশনটি ধাপে ধাপে তৈরি করুন। আরও পরিচালনাযোগ্য একটি অবকাঠামো খুঁজছেন? Hostragons-এর হোস্টিং প্যাকেজ, ভিপিএস সার্ভার এবং এসএসএল সার্টিফিকেট সমাধানগুলো পর্যালোচনা করে আপনার প্রকল্পের জন্য উপযুক্ত সূচনাবিন্দু নির্বাচন করতে পারেন।

সাধারণ জিজ্ঞাসা

Nginx সার্ভার ব্লক দিয়ে কতটি সাইট হোস্ট করা যেতে পারে?

প্রযুক্তিগতভাবে Nginx-এর মাধ্যমে একই সার্ভারে অনেক সাইট হোস্ট করা সম্ভব; সীমাটি সাধারণত CPU, RAM, ডিস্ক, ট্রাফিক, ডেটাবেস লোড এবং PHP-FPM ক্ষমতার উপর নির্ভর করে। কম ট্রাফিকের স্ট্যাটিক সাইটগুলোতে দশকের সাইট সম্ভব হলেও, উচ্চ ট্রাফিকের WordPress বা ই-কমার্স প্রকল্পগুলোর ক্ষেত্রে কম সাইট হোস্ট করা স্বাস্থ্যকর।

প্রতিটি সাইটের জন্য আলাদা SSL সার্টিফিকেট প্রয়োজন কি?

হ্যাঁ, প্রতিটি ডোমেন বা সাবডোমেন যদি HTTPS-এর মাধ্যমে প্রকাশিত হয় তবে সার্টিফিকেটের আওতায় অন্তর্ভুক্ত হতে হবে। একক সার্টিফিকেট ব্যবহার করা যেতে পারে, SAN বা ওয়ার্কড সার্টিফিকেটও পছন্দ করা যেতে পারে। গুরুত্বপূর্ণ বিষয় হল Nginx 443 সার্ভার ব্লকে সঠিক সার্টিফিকেট ফাইলগুলো সঠিক ডোমেনের সাথে সংযুক্ত করা।

Nginx সার্ভার ব্লক ব্যবহার করে সাবডোমেইন প্রকাশ করা যায়?

হ্যাঁ। blog.site.com অথবা panel.site.com-এর মতো সাবডোমেইনগুলির জন্য আলাদা server_name সংজ্ঞায়িত করা যেতে পারে এবং ভিন্ন রুট ডিরেক্টরিতে বা ভিন্ন ব্যাকএন্ড অ্যাপ্লিকেশনে রিডাইরেক্ট করা যেতে পারে। DNS পক্ষে সংশ্লিষ্ট সাবডোমেইনের জন্য A বা CNAME রেকর্ড তৈরি করতে হবে।

sites-available এবং sites-enabled মধ্যে পার্থক্য কী?

sites-available হলো উপলব্ধ কনফিগারেশন ফাইলগুলো সংরক্ষণের স্থান; sites-enabled সক্রিয় কনফিগারেশনগুলো ধারণ করে। সাধারণত sites-enabled-এ sites-available ফাইলের জন্য একটি প্রতীকী লিঙ্ক তৈরি করা হয়। এই পদ্ধতি সাইটগুলোকে সক্রিয় এবং নিষ্ক্রিয় করতে আরও নিয়মিত করে তোলে।

ভুল সাইট খোলার সময় সমস্যা কোথায় হতে পারে?

সর্বাধিক সাধারণ কারণ হল DNS-এর ভুল IP-তে নির্দেশ করা, server_name মানের ত্রুটি, ডিফল্ট Nginx ব্লকের অনুরোধটি গ্রহণ করা অথবা 443 পোর্টের ভুল SSL ব্লক কার্যকর হচ্ছে। প্রথমে DNS রেকর্ডগুলো, পরে nginx -t আউটপুট, সক্রিয় sites-enabled লিঙ্কগুলো এবং সম্পর্কিত access_log ফাইলগুলো পরীক্ষা করুন।