Nginx নিজে সাধারণত অ্যাপ্লিকেশন কোড চালায় না; এটি PHP-FPM, Node.js, Python বা অন্য অ্যাপ সার্ভারের সামনে reverse proxy হিসেবে কাজ করে। কোন আর্কিটেকচার দ্রুত, নিরাপদ ও খরচসাশ্রয়ী হবে, কনফিগারেশন, স্কেলিং ও হোস্টিং নির্বাচনের মূল মানদণ্ডসহ জানুন।
Nginx নিজে সাধারণত PHP, Node.js বা Python অ্যাপের কোড চালায় না; এটি অ্যাপ্লিকেশন সার্ভারের সামনে থেকে অনুরোধ গ্রহণ, নিরাপত্তা ও ট্রাফিক নিয়ন্ত্রণ করে। PHP সাইটে Nginx-এর সঙ্গে PHP-FPM, আর API বা WebSocket-ভিত্তিক অ্যাপে আলাদা Node.js বা অন্য অ্যাপ প্রসেসের সামনে reverse proxy মডেল বেশি যুক্তিযুক্ত। ছোট ব্যবসার সাইটে সহজ পরিচালনা দরকার হলে managed hosting বিবেচনা করা যায়, আর নিয়ন্ত্রণ ও কাস্টম কনফিগারেশন দরকার হলে VPS বা ক্লাউড সার্ভার উপযোগী হতে পারে। সঠিক পছন্দ নির্ভর করে ট্রাফিক, ডাটাবেস, আপলোড, ব্যাকআপ, দলের দক্ষতা ও সহায়তার প্রয়োজনের ওপর। কনফিগারেশনে সামান্য ভুলেও 404, 502, redirect loop বা ভুল ক্লায়েন্ট IP দেখা দিতে পারে। তাই শুরুতেই আর্কিটেকচার, দায়িত্বের সীমা এবং পর্যবেক্ষণের ব্যবস্থা পরিষ্কার রাখা ভালো।
এক নজরে
- Nginx স্ট্যাটিক ফাইল পরিবেশন, SSL/TLS সমাপ্তি, ক্যাশিং, লোড ব্যালান্সিং ও reverse proxy হিসেবে কাজ করতে পারে।
- PHP-ভিত্তিক সাইটে Nginx সাধারণত FastCGI-এর মাধ্যমে PHP-FPM-এ অনুরোধ পাঠায়; Node.js বা Python অ্যাপ আলাদা প্রসেসে চলে।
- কম পরিচালনা-ঝামেলা চাইলে managed hosting, আর নিয়ন্ত্রণ ও কাস্টম স্কেলিং চাইলে VPS বা ক্লাউড সার্ভার তুলনা করে বেছে নেওয়া উচিত।
| মডেল | কখন উপযুক্ত | Nginx-এর ভূমিকা | দায়িত্ব ও বিবেচনা |
|---|---|---|---|
| PHP-FPM | CMS, ব্যবসায়িক সাইট, PHP-নির্ভর দোকান | স্ট্যাটিক ফাইল সরবরাহ ও FastCGI অনুরোধ পাঠানো | PHP-FPM, socket, try_files ও FastCGI প্যারামিটার ঠিক রাখা |
| Node.js বা অন্য অ্যাপ সার্ভার | API, SaaS, JavaScript অ্যাপ, WebSocket | HTTP reverse proxy, SSL/TLS ও header ফরওয়ার্ড করা | অ্যাপ প্রসেস, timeout, proxy header ও স্কেলিং পর্যবেক্ষণ |
| Managed platform বা managed hosting | দলের সার্ভার পরিচালনার সময় বা দক্ষতা সীমিত হলে | প্ল্যাটফর্মভেদে আংশিক বা পূর্ণ ব্যবস্থাপনা | ব্যাকআপ, SLA, সহায়তা, সীমাবদ্ধতা ও মাসিক ব্যয় যাচাই |
ডাইনামিক অনুরোধে Nginx-এর আসল ভূমিকা কী
Nginx হলো ওয়েব সার্ভার ও ট্রাফিকের সামনের স্তর, কিন্তু বেশির ভাগ ক্ষেত্রে এটি আপনার অ্যাপ্লিকেশনের ব্যবসায়িক লজিক চালানোর রানটাইম নয়। ব্রাউজার থেকে আসা অনুরোধ আগে Nginx গ্রহণ করে। ফাইলটি ছবি, CSS, JavaScript বা অন্য স্ট্যাটিক সম্পদ হলে Nginx সরাসরি পাঠাতে পারে। আর লগইন, পণ্য অনুসন্ধান, ড্যাশবোর্ড বা API-এর মতো ডাইনামিক অনুরোধ অ্যাপ্লিকেশন রানটাইমে পাঠানো হয়।
স্ট্যাটিক ফাইল, reverse proxy ও অ্যাপ্লিকেশন রানটাইমের পার্থক্য
স্ট্যাটিক ফাইলের বিষয়টি তুলনামূলক সহজ: সার্ভারে ফাইল আছে, Nginx সেটি পাঠায়। Reverse proxy ক্ষেত্রে Nginx অনুরোধটি পেছনের অ্যাপ সার্ভারে পাঠায় এবং উত্তরটি ব্যবহারকারীর কাছে ফেরত দেয়। PHP-এর জন্য এই সংযোগটি সাধারণত PHP-FPM ও FastCGI দিয়ে হয়। Node.js, Python, Ruby বা Java অ্যাপের ক্ষেত্রে Nginx সাধারণত HTTP reverse proxy হিসেবে সামনে থাকে।
এই বিভাজনের সুবিধা হলো একটি জায়গায় HTTPS, নিরাপত্তা হেডার, রেট লিমিটিং, ক্যাশিং এবং লোড ব্যালান্সিং নীতি রাখা যায়। তবে এতে দায়িত্বও ভাগ হয়: Nginx সচল থাকলেও পেছনের অ্যাপ প্রসেস বন্ধ থাকলে ব্যবহারকারী সঠিক উত্তর পাবেন না।
কোন অনুরোধ Nginx সামলাবে, কোনটি অ্যাপ সার্ভারে যাবে
সাধারণ নীতি হলো: অপরিবর্তনশীল ফাইল Nginx সামলাবে, আর ব্যবহারকারীভিত্তিক বা ডাটাবেসনির্ভর ফলাফল অ্যাপ সার্ভারে যাবে। যেমন, ওয়েবসাইটের লোগো বা স্টাইলশিট Nginx থেকে দেওয়া যেতে পারে। কিন্তু কার্ট, ব্যবহারকারী প্রোফাইল, অর্ডার অবস্থা বা API ফলাফল অ্যাপ্লিকেশন প্রসেস থেকে আসবে।
এখানে root এবং try_files পরিকল্পনা গুরুত্বপূর্ণ। ভুল root থাকলে ফাইল পাওয়া যাবে না। ভুল try_files হলে বৈধ রুট 404 দিতে পারে অথবা অপ্রয়োজনীয়ভাবে সব অনুরোধ অ্যাপে চলে যেতে পারে।
PHP-FPM, Node.js প্রক্সি ও managed platform—কোন মডেল কখন উপযুক্ত
একটি মডেল সবার জন্য সেরা নয়। আপনার অ্যাপের ভাষা, দল, ট্রাফিকের ধরন, অপারেশনাল ঝুঁকি এবং সার্ভার ব্যবস্থাপনার সক্ষমতা একসঙ্গে বিবেচনা করতে হবে।
ছোট ব্যবসার CMS বা PHP সাইটের জন্য PHP-FPM
PHP-ভিত্তিক CMS, কনটেন্ট সাইট বা সাধারণ অনলাইন দোকানের ক্ষেত্রে Nginx + PHP-FPM একটি পরিচিত কাঠামো। Nginx স্ট্যাটিক সম্পদ সরবরাহ করে এবং PHP প্রয়োজন এমন অনুরোধ PHP-FPM-এ পাঠায়। এতে ওয়েব সার্ভার ও PHP রানটাইমের দায়িত্ব আলাদা থাকে।
তবে শুধু PHP-FPM বসালেই কাজ শেষ নয়। সঠিক FastCGI প্যারামিটার, স্ক্রিপ্টের ফাইলপথ, socket বা সংযোগের অবস্থান এবং অ্যাপের রাউটিং মিলিয়ে দেখতে হয়। বিশেষ করে CMS-এর permalink বা রিরাইট নিয়ম থাকলে try_files ভুল হলে পৃষ্ঠা না খোলা, 404 বা redirect সমস্যার ঝুঁকি থাকে।
API, WebSocket ও JavaScript অ্যাপের জন্য upstream অ্যাপ সার্ভার
Node.js, Python, Ruby বা Java অ্যাপ সাধারণত নিজস্ব অ্যাপ্লিকেশন প্রসেসে চলে। Nginx-এর কাজ হলো বাইরের HTTP অনুরোধকে upstream অ্যাপ সার্ভারে পৌঁছে দেওয়া। API বা SaaS পণ্যে এই কাঠামো উপযোগী হতে পারে, কারণ একই অ্যাপের একাধিক ইনস্ট্যান্সে ট্রাফিক ভাগ করা যায়।
WebSocket ব্যবহার করলে প্রক্সি কনফিগারেশনে সংযোগের ধরন ও প্রয়োজনীয় header ঠিকভাবে ফরওয়ার্ড হচ্ছে কি না দেখা জরুরি। সাধারণ ওয়েবপেজের মতো ধরে কনফিগার করলে রিয়েল-টাইম সংযোগ ব্যর্থ হতে পারে। API-এর ক্ষেত্রে timeout-ও বাস্তব ব্যবহার অনুযায়ী নির্ধারণ করা দরকার; খুব কম হলে বৈধ অনুরোধ কেটে যেতে পারে, আর অযথা দীর্ঘ হলে ব্যর্থ অনুরোধ বেশি সময় ধরে রিসোর্স আটকে রাখতে পারে।
নিজস্ব সার্ভার ব্যবস্থাপনা বনাম managed hosting-এর মূল্য ও দায়িত্ব তুলনা
VPS বা ক্লাউড সার্ভার নিলে কনফিগারেশন, আপডেট, লগ, ব্যাকআপ, নিরাপত্তা এবং সমস্যা সমাধানে আপনার বা দলের বেশি নিয়ন্ত্রণ থাকে। এই নিয়ন্ত্রণ কাস্টম অ্যাপ ও বিশেষ স্কেলিং চাহিদায় কার্যকর হতে পারে। তবে সেটির সঙ্গে নিয়মিত সার্ভার ব্যবস্থাপনার দায়িত্বও আসে।
Managed hosting বা managed server-এ কিছু অপারেশনাল কাজ সেবাদাতা সামলাতে পারে, কিন্তু কী অন্তর্ভুক্ত তা পরিষ্কারভাবে যাচাই করা জরুরি। ব্যাকআপ কি আছে, পুনরুদ্ধারের প্রক্রিয়া কী, সহায়তার স্তর কেমন, SSL/TLS বা CDN ব্যবস্থাপনা কীভাবে হয় এবং কোন সীমাবদ্ধতা আছে—এসব দেখুন। শুধুমাত্র মাসিক খরচ দেখে সিদ্ধান্ত নিলে পরে পরিচালনা বা সহায়তার ঘাটতি দেখা দিতে পারে।
উৎপাদন পরিবেশের কনফিগারেশন ধাপ ও নিরাপত্তা সতর্কতা
উৎপাদন পরিবেশে Nginx কনফিগারেশনকে শুধু “সাইট খুলছে কি না” দিয়ে বিচার করা যথেষ্ট নয়। সঠিক রাউটিং, নিরাপত্তা, আপলোড নীতি এবং ব্যর্থতার সময় আচরণও পরিকল্পনার অংশ।
server block, try_files এবং FastCGI বা proxy pass-এর পরিকল্পনা
প্রতিটি ডোমেইন বা অ্যাপের জন্য server block-এ কোন hostname গ্রহণ হবে, কোথায় স্ট্যাটিক ফাইল আছে এবং কোন অনুরোধ অ্যাপ সার্ভারে যাবে তা নির্ধারণ করুন। PHP সাইটে FastCGI-র গন্তব্য ও প্রয়োজনীয় প্যারামিটার সামঞ্জস্যপূর্ণ হওয়া দরকার। অন্য অ্যাপে proxy pass ব্যবহার করে upstream অ্যাপ সার্ভারের ঠিকানা নির্ধারিত হয়।
পরিবর্তন করার আগে বর্তমান কনফিগারেশনের কপি রাখা এবং পরিবর্তনের পর লগ দেখা নিরাপদ অভ্যাস। একটি ছোট পরিবর্তনও যদি root, রাউটিং বা header-এর আচরণ বদলে দেয়, তাহলে অ্যাপের নির্দিষ্ট অংশে সমস্যা দেখা দিতে পারে।
HTTPS, forwarded header, আপলোড সীমা ও timeout নির্ধারণ
HTTPS ব্যবহারে Nginx SSL/TLS সমাপ্তির জায়গা হতে পারে। অ্যাপ সার্ভারকে মূল অনুরোধের তথ্য জানাতে forwarded header সঠিকভাবে পাঠানো গুরুত্বপূর্ণ। না হলে অ্যাপ ভুল প্রোটোকল বুঝতে পারে, redirect loop তৈরি হতে পারে অথবা আসল ক্লায়েন্ট IP-এর বদলে প্রক্সির IP দেখতে পারে।
ফাইল আপলোড থাকলে অনুরোধের আকারসীমা বাস্তব প্রয়োজন অনুযায়ী ঠিক করতে হবে। খুব কম সীমায় বৈধ আপলোড ব্যর্থ হতে পারে। একইভাবে timeout অ্যাপের কাজের ধরন বিবেচনা করে নির্ধারণ করুন। নিরাপত্তার জন্য rate limiting, নিরাপত্তা হেডার এবং অনাবশ্যক endpoint সুরক্ষার বিষয়ও বিবেচনা করা উচিত।
ক্যাশ যুক্ত করার আগে ডাইনামিক ব্যবহারকারী ডেটা যাচাই
ক্যাশিং কর্মদক্ষতায় সহায়তা করতে পারে, কিন্তু ব্যবহারকারীভিত্তিক ডেটা ভুলভাবে ক্যাশ হলে এক ব্যবহারকারীর তথ্য অন্য ব্যবহারকারীর কাছে যাওয়ার ঝুঁকি তৈরি হতে পারে। লগইন, কার্ট, অ্যাকাউন্ট পৃষ্ঠা, ব্যক্তিগত ড্যাশবোর্ড ও অনুমতিনির্ভর API-এর ক্যাশ নীতি আলাদা করে যাচাই করুন। ক্যাশ চালুর আগে কোন উত্তর সর্বজনীন আর কোনটি ব্যক্তিগত, সেটি স্পষ্ট হওয়া দরকার।
সাধারণ ত্রুটি এড়ানো ও কর্মদক্ষতা পর্যবেক্ষণ
Nginx-এর ত্রুটি বার্তা দেখে শুধু ওয়েব সার্ভারকে দায়ী করলে সমাধান বিলম্বিত হয়। সমস্যা Nginx, অ্যাপ প্রসেস, socket, ডাটাবেস, নেটওয়ার্ক বা কনফিগারেশনের পারস্পরিক সম্পর্কেও হতে পারে।
502 ও 504 ত্রুটিতে অ্যাপ প্রসেস, socket এবং timeout পরীক্ষা
502 Bad Gateway দেখা দিলে আগে পেছনের অ্যাপ প্রসেস চলছে কি না দেখুন। PHP-FPM হলে FastCGI গন্তব্য, socket-এর প্রাপ্যতা ও অনুমতি যাচাই করা দরকার। Node.js বা অন্য অ্যাপ হলে নির্ধারিত upstream ঠিকানায় প্রসেস সাড়া দিচ্ছে কি না দেখতে হবে।
504 Gateway Timeout সাধারণত নির্ধারিত সময়ের মধ্যে upstream থেকে উত্তর না এলে দেখা দিতে পারে। তখন timeout বাড়ানোর আগে অ্যাপ কেন ধীর হচ্ছে তা খতিয়ে দেখা ভালো। ডাটাবেস, দীর্ঘ অনুরোধ, ফাইল প্রসেসিং বা রিসোর্স সীমা প্রভাব ফেলছে কি না পর্যবেক্ষণ করুন।
redirect loop, ভুল base URL ও ক্লায়েন্ট IP সমস্যার সমাধান
HTTPS শেষে অ্যাপ যদি নিজেকে HTTP হিসেবে দেখে, তাহলে বারবার পুনর্নির্দেশ বা redirect loop হতে পারে। প্রক্সির মাধ্যমে আসা scheme ও host সম্পর্কিত তথ্য অ্যাপ সঠিকভাবে পাচ্ছে কি না মিলিয়ে দেখুন। অ্যাপের base URL-ও প্রকৃত পাবলিক URL-এর সঙ্গে সামঞ্জস্যপূর্ণ হতে হবে।
ভুল ক্লায়েন্ট IP-এর সমস্যা হলে অ্যাপ সব ব্যবহারকারীকে একই প্রক্সি IP হিসেবে দেখতে পারে। এতে rate limiting, অডিট লগ বা নিরাপত্তা নিয়ম ভুলভাবে কাজ করতে পারে। forwarded header-এর ব্যবহার ও অ্যাপের trusted proxy সেটিং একে অপরের সঙ্গে সামঞ্জস্যপূর্ণ হওয়া প্রয়োজন।
লগ, uptime monitoring ও ব্যাকআপ যাচাইয়ের ন্যূনতম তালিকা
ন্যূনতমভাবে Nginx-এর access ও error log, অ্যাপ্লিকেশন লগ এবং সার্ভিসের প্রাপ্যতা পর্যবেক্ষণের ব্যবস্থা রাখুন। শুধু ব্যাকআপ আছে বললেই যথেষ্ট নয়; পুনরুদ্ধারের প্রক্রিয়া বোঝা ও সময়মতো যাচাই করা দরকার। আপডেট বা কনফিগারেশন বদলের আগে কোন ফাইল, ডাটাবেস ও পরিবেশগত সেটিং সংরক্ষণ করতে হবে, সেটিও তালিকাভুক্ত রাখুন।
ট্রাফিক ও দলের সক্ষমতাভেদে স্থাপনা পরিকল্পনা
সঠিক স্থাপনা সাধারণত সবচেয়ে জটিল স্থাপনা নয়। বর্তমান প্রয়োজন মেটানোর পাশাপাশি পরিবর্তন ও বৃদ্ধির সময় কীভাবে এগোবেন, সেটি জানাই বেশি গুরুত্বপূর্ণ।
কম ট্রাফিকের কর্পোরেট সাইট বা অনলাইন দোকান
কম ট্রাফিকের কর্পোরেট সাইট, কনটেন্ট সাইট বা ছোট অনলাইন দোকানে PHP-FPM-সহ Nginx অথবা একটি উপযুক্ত managed hosting পরিকল্পনা ব্যবহারযোগ্য হতে পারে। এখানে অগ্রাধিকার হতে পারে নির্ভরযোগ্য ব্যাকআপ, HTTPS, আপডেট এবং দ্রুত সহায়তা। যদি দলের নিয়মিত সার্ভার দেখার সময় না থাকে, managed server-এর সহায়তা স্তর যাচাই করা বাস্তবসম্মত সিদ্ধান্ত হতে পারে।
বাড়তে থাকা API বা SaaS পণ্যের জন্য স্কেলিং প্রস্তুতি
API বা SaaS পণ্যে ব্যবহার বাড়লে অ্যাপের একাধিক ইনস্ট্যান্স চালিয়ে Nginx-এর মাধ্যমে ট্রাফিক ভাগ করার পরিকল্পনা দরকার হতে পারে। Nginx upstream কনফিগারেশনে একাধিক অ্যাপ সার্ভারে লোড ব্যালান্সিং করা যায়। তবে স্কেলিং শুধু অ্যাপ সার্ভারের বিষয় নয়; ডাটাবেস, ক্যাশ, ফাইল আপলোড এবং উচ্চপ্রাপ্যতার প্রয়োজনও সমান গুরুত্বপূর্ণ।
শুরু থেকেই কোন অংশটি stateless, কোন অংশে ব্যবহারকারী সেশন আছে এবং কোন নির্ভরতা একক সার্ভারে আটকে আছে তা নথিভুক্ত করুন। এতে ক্লাউড হোস্টিং বা অ্যাপ্লিকেশন সার্ভার বাড়ানোর সিদ্ধান্ত বেশি পরিষ্কার হবে।
কখন সার্ভার অ্যাডমিন বা DevOps সেবা নেওয়া যুক্তিযুক্ত
নিয়মিত 502/504, ডিপ্লয়মেন্ট জটিলতা, নিরাপত্তা আপডেট, লগ বিশ্লেষণ, ব্যাকআপ পুনরুদ্ধার বা ট্রাফিক বৃদ্ধির প্রস্তুতি যদি দলের স্বাভাবিক কাজ ব্যাহত করে, তাহলে DevOps সহায়তা বা সার্ভার অ্যাডমিন সেবা বিবেচনা করা যেতে পারে। এটি সব প্রতিষ্ঠানের জন্য বাধ্যতামূলক নয়। কিন্তু কনফিগারেশন-নির্ভর ঝুঁকি বেশি হলে দায়িত্বের পরিধি ও সহায়তার সময়সীমা আগে থেকেই পরিষ্কার করা জরুরি।
নির্বাচনের মানদণ্ড ও তুলনা সারাংশ
সিদ্ধান্ত নেওয়ার আগে এই বিষয়গুলো মিলিয়ে দেখুন: অ্যাপের ভাষা ও ফ্রেমওয়ার্ক, প্রত্যাশিত ট্রাফিক, RAM/CPU প্রয়োজন, ডাটাবেস ও ক্যাশের চাপ, ফাইল আপলোড, ব্যাকআপ, নিরাপত্তা, সহায়তার স্তর এবং মাসিক ব্যয়ের কাঠামো। VPS নিলে আপনি কতটা সার্ভার ব্যবস্থাপনা করবেন, managed cloud নিলে কোন কাজ সেবাদাতা করবে, আর DevOps সহায়তা নিলে কী ধরনের প্রতিক্রিয়া পাবেন—এসব লিখিতভাবে তুলনা করুন।
ক্লাউড হোস্টিং, managed server বা CDN বাছাইয়ের আগে তাদের অফিসিয়াল পৃষ্ঠায় ব্যাকআপ, সহায়তা, SLA, রিসোর্স সীমা এবং নিরাপত্তা বৈশিষ্ট্য দেখে নিন।
শেষ কথা
Nginx দিয়ে ডাইনামিক কনটেন্ট পরিবেশন মানে Nginx-কে অ্যাপ রানটাইম ভাবা নয়; বরং সঠিক অ্যাপ সার্ভারের সামনে একটি নিয়ন্ত্রণ স্তর হিসেবে ব্যবহার করা। PHP সাইটে PHP-FPM, আর Node.js বা অন্যান্য অ্যাপে reverse proxy কাঠামো সাধারণত পরিষ্কার দায়িত্ববণ্টন দেয়। ছোট শুরু হলেও লগ, HTTPS, ব্যাকআপ ও ত্রুটি পর্যবেক্ষণ বাদ দেওয়া উচিত নয়। ট্রাফিক ও দলের সক্ষমতা বদলালে স্থাপনা পরিকল্পনাও পুনর্মূল্যায়ন করুন।
জেনে রাখার মতো উপকারী তথ্য
১. Nginx-এর সামনে SSL/TLS রাখলে অ্যাপ সার্ভারের HTTPS সম্পর্কিত তথ্য সঠিকভাবে পৌঁছাচ্ছে কি না পরীক্ষা করুন।
২. ক্যাশ চালুর আগে ব্যক্তিগত ও সর্বজনীন কনটেন্ট আলাদা করুন।
৩. 502 দেখলেই শুধু Nginx পুনরায় চালু না করে upstream অ্যাপ প্রসেস ও লগ দেখুন।
৪. একাধিক অ্যাপ ইনস্ট্যান্স চালানোর আগে সেশন, ডাটাবেস ও ফাইলের নির্ভরতা বুঝে নিন।
গুরুত্বপূর্ণ বিষয়গুলোর সারাংশ
নির্দিষ্ট সার্ভার ক্ষমতা, হোস্টিং খরচ বা কোন managed service সবচেয়ে সাশ্রয়ী হবে তা ব্যবহার, অঞ্চল, সহায়তার স্তর ও SLA অনুযায়ী বদলায়। কনফিগারেশন পরিবর্তনের ফলে কর্মদক্ষতা বা নিরাপত্তা কতটা বদলাবে, তা পরীক্ষা ও মনিটরিং ছাড়া নিশ্চিতভাবে বলা যায় না। লাইভ পরিবেশে পরিবর্তনের আগে বিদ্যমান কনফিগারেশন, অ্যাপ সেটিং এবং ব্যাকআপ পুনরুদ্ধার পদ্ধতি যাচাই করুন।
সাধারণ জিজ্ঞাসা
Q1. Nginx কি PHP বা Node.js কোড সরাসরি চালাতে পারে?
A1. সাধারণভাবে Nginx PHP বা Node.js কোডের রানটাইম নয়। PHP-এর জন্য এটি PHP-FPM-এ FastCGI অনুরোধ পাঠায়। Node.js অ্যাপ সাধারণত আলাদা প্রসেসে চলে, আর Nginx তার সামনে HTTP reverse proxy হিসেবে থাকে।
Q2. ছোট ব্যবসার ডাইনামিক ওয়েবসাইটের জন্য VPS নাকি managed hosting বেশি উপযোগী?
A2. কাস্টম কনফিগারেশন ও সার্ভার পরিচালনার দক্ষতা থাকলে VPS বা ক্লাউড সার্ভার বিবেচনা করা যায়। নিয়মিত আপডেট, ব্যাকআপ, নিরাপত্তা ও সমস্যা সমাধানের দায়িত্ব কমাতে চাইলে managed hosting উপযোগী হতে পারে। সিদ্ধান্তের আগে সহায়তা, ব্যাকআপ, SLA, সীমাবদ্ধতা ও মোট মাসিক ব্যয় তুলনা করুন।
Q3. Nginx reverse proxy ব্যবহার করলে 502 Bad Gateway এড়াতে কোন বিষয়গুলো আগে পরীক্ষা করা উচিত?
A3. আগে upstream অ্যাপ প্রসেস চলছে কি না, সঠিক socket বা ঠিকানায় সাড়া দিচ্ছে কি না এবং Nginx-এর proxy বা FastCGI গন্তব্য ঠিক আছে কি না দেখুন। এরপর error log, timeout এবং অ্যাপের নিজস্ব ত্রুটি পরীক্ষা করুন।
