শেয়ার্ড হোস্টিংয়ে Cloudflare সেটআপ — ফ্রি সিডিএন ও এসএসএল | এস টেকনোলজিস

Cloudflare বসে আপনার ভিজিটর আর সার্ভারের মাঝখানে। রিকোয়েস্ট প্রথমে তাদের নেটওয়ার্কে যায়, সম্ভব হলে কাছাকাছি ক্যাশ থেকেই উত্তর পায়, আর একান্ত দরকার হলেই কেবল আপনার হোস্টে পৌঁছায়।

শেয়ার্ড হোস্টিংয়ে এর দাম বড় সার্ভারের চেয়েও বেশি, কারণ Cloudflare যে ট্র্যাফিক শুষে নেয় সেটি আর আপনার কেনা রিসোর্স লিমিটে হাত দেয় না। যে সাইট তার বেশিরভাগ ছবি ও সিএসএস Cloudflare থেকে দেয়, সেটি অন্যথায় যত এন্ট্রি প্রসেস আর I/O লাগত তার সামান্য অংশই ব্যবহার করে।

এটি ফ্রি, সময় লাগে আধা ঘণ্টার মতো, আর ভুল হয় ঠিক দুই জায়গায়। দুটিই নিচে আছে, সমাধানসহ।

ফ্রি প্যাকেজে কী পাওয়া যায়

এটা নির্দিষ্ট করে বলা দরকার, কারণ বিজ্ঞাপন বিষয়টা ঘোলাটে করে রাখে:

স্ট্যাটিক ফাইলের জন্য গ্লোবাল সিডিএন — ছবি, সিএসএস, জাভাস্ক্রিপ্ট। ভিজিটরের কাছাকাছি ক্যাশ করা।
ডিএনএস হোস্টিং, যা বেশিরভাগ হোস্টের নিজস্ব ডিএনএসের চেয়ে দ্রুত ও সহজ।
ভিজিটর ও Cloudflare-এর মধ্যে ফ্রি এসএসএল সার্টিফিকেট।
DDoS প্রতিরোধ, সত্যিই ভালো, সত্যিই ফ্রি।
একটি ফায়ারওয়াল, যার জন্য নিজে নিয়ম লেখা যায়।
Brotli কমপ্রেশন, HTTP/3, আর স্বয়ংক্রিয় HTTPS রিরাইটিং।

যা ফ্রিতে পাবেন না: ডিফল্টভাবে HTML পেজের ক্যাশিং (শুধু স্ট্যাটিক অ্যাসেট, যদি না নিজে নিয়ম লেখেন), ছবি রিসাইজ, বা নিশ্চিত এসএলএ।

প্রথমটি গুরুত্বপূর্ণ। বাক্স থেকে বের করে বসালে Cloudflare আপনার পেজ ক্যাশ করে না — করে আপনার অ্যাসেট। সেটাও বড় লাভ, কিন্তু আপনি যদি ভেবে থাকেন WordPress হোমপেজ এজ থেকে আসবে, তা আসবে না — যতক্ষণ না আপনি বলে দেন।

শুরুর আগে

দুটি জিনিস হাতে রাখুন:

ডোমেইন রেজিস্ট্রারে প্রবেশাধিকার, কারণ নেমসার্ভার সেখানেই বদলাবেন। ডোমেইনটি আমরা রেজিস্টার করে থাকলে সেটি ক্লায়েন্ট এরিয়া।
হোস্টিংয়ে একটি কার্যকর এসএসএল সার্টিফিকেট, AutoSSL বা Let's Encrypt থেকে। পরে সঠিক এসএসএল মোডের জন্য এটি লাগবে; সাইট এখনো https-এ না থাকলে আগে সেটি ঠিক করুন — আমাদের প্রতিটি হোস্টিং প্যাকেজের সঙ্গেই ফ্রি সার্টিফিকেট আসে।

সার্ভারের আইপি ঠিকানাটাও লিখে রাখুন। পরে কিছু যাচাই করতে হলে কাজে লাগবে, আর Cloudflare প্রক্সি শুরু করলে ডিএনএস লুকআপে সেটি আর দেখা যাবে না।

ধাপ ১ — সাইট যোগ করুন আর রেকর্ড মিলিয়ে নিন

সাইনআপ করুন, ডোমেইন যোগ করুন, আর Cloudflare-কে আপনার বিদ্যমান ডিএনএস স্ক্যান করতে দিন। বেশিরভাগ রেকর্ড নিজেই নিয়ে নেবে। তারপর এগোনোর আগেই হোস্টের ডিএনএসের সঙ্গে মিলিয়ে দেখুন, কারণ যেটি বাদ পড়েছে সেটি নেমসার্ভার বদলানোর সঙ্গে সঙ্গেই কাজ করা বন্ধ করবে।

যেগুলো সবচেয়ে বেশি বাদ পড়ে:

MX রেকর্ড — আপনার ইমেইল। এগুলো ভুল হলে মেইল বন্ধ। গোটা প্রক্রিয়ার সবচেয়ে ক্ষতিকর ভুল এটাই।
SPF, DKIM ও DMARC-এর TXT রেকর্ড। এগুলো না থাকলে মেইল সঙ্গে সঙ্গে বন্ধ হয় না, চুপচাপ স্প্যামে চলে যায়।
সম্পূর্ণ অন্য কোথাও থাকা সাবডোমেইনের রেকর্ড।

প্রতিটি রেকর্ডের পাশের কমলা মেঘটাই আসল নিয়ন্ত্রণ:


কমলা (প্রক্সিড)	ট্র্যাফিক Cloudflare হয়ে যায়। `@` ও `www`-এর জন্য এটি।
ধূসর (শুধু ডিএনএস)	Cloudflare কেবল লুকআপের উত্তর দেয়। মেইল ও http নয় এমন সবকিছুর জন্য এটি।

মেইল রেকর্ড ধূসর হতেই হবে। Cloudflare http ও https প্রক্সি করে, SMTP বা IMAP নয় — তাই মেইল হোস্টে কমলা মেঘ মানে ইমেইল বন্ধ।

ধাপ ২ — নেমসার্ভার বদলান

Cloudflare আপনাকে দুটি নেমসার্ভার দেবে। রেজিস্ট্রারে সেগুলো বসান, যা ছিল তার বদলে।

প্রোপাগেশন সাধারণত কয়েক মিনিট, কখনো একদিন। ওই সময়টায় কিছু ভিজিটর পুরোনো উত্তর পাবেন, কিছু নতুন — সেটা ঠিক আছে, যতক্ষণ দুটোই কার্যকর সাইটের দিকে দেখায়। তাই প্রোপাগেশন শেষ না হওয়া পর্যন্ত সার্ভারে কিছু বদলাবেন না।

ধাপ ৩ — এসএসএল মোড ঠিক করুন। এটাই এক নম্বর ভুল।

SSL/TLS → Overview, সেখানে চারটি অপশন। এখানে ভুল বাছাই থেকেই Cloudflare-এর বেশিরভাগ সমস্যা হয়, কুখ্যাত রিডাইরেক্ট লুপসহ।

মোড	ভিজিটর → Cloudflare	Cloudflare → আপনার সার্ভার	রায়
Off	http	http	না।
Flexible	https	http	কখনোই নয়।
Full	https	https, সার্টিফিকেট যাচাই হয় না	চলনসই
Full (strict)	https	https, সার্টিফিকেট যাচাই হয়	সঠিক

Flexible-ই ফাঁদ। এটি ভিজিটরকে তালা দেখায়, অথচ Cloudflare থেকে আপনার সার্ভার পর্যন্ত সংযোগটি সাধারণ http — অর্থাৎ সাইটটি নিরাপদ দেখায়, নিরাপদ নয়, আর মাঝখানের যে কেউ ট্র্যাফিক পড়তে পারে। রিডাইরেক্ট লুপও এখান থেকেই: আপনার সার্ভার http রিকোয়েস্ট দেখে https-এ পাঠায়, Cloudflare আবার http-তেই পাঠায়, অনন্তকাল। Cloudflare যোগ করার পর কখনো ERR_TOO_MANY_REDIRECTS দেখে থাকলে কারণ এটাই।

Full (strict) ব্যবহার করুন। এর জন্য সার্ভারে বৈধ সার্টিফিকেট লাগে, যা AutoSSL থেকে আপনার আগেই আছে, আর এটিই একমাত্র মোড যেখানে শুরু থেকে শেষ পর্যন্ত এনক্রিপ্টেড।

তারপর একই জায়গায়:

Always Use HTTPS — চালু।
Automatic HTTPS Rewrites — চালু। এটি পেজে হার্ড-কোড করা http অ্যাসেট URL ঠিক করে দেয়, যা পুরোনো WordPress সাইটে মিক্সড-কনটেন্ট সতর্কবার্তার সাধারণ কারণ।
Minimum TLS Version — ১.২।

ধাপ ৪ — ক্যাশিং

Caching → Configuration:

Caching Level: Standard।
Browser Cache TTL: অন্তত কয়েক ঘণ্টা; অ্যাসেট ভার্সন করা থাকলে আরও বেশি।

তারপর দুটি নিয়ম। নতুন ড্যাশবোর্ডে এগুলো Rules → Cache Rules-এ — পুরোনো Page Rules এখনো চলে, তবে ধীরে ধীরে তুলে দেওয়া হচ্ছে।

নিয়ম ১ — অ্যাডমিন কখনো ক্যাশ নয়। WordPress-এর জন্য:

text

URI Path starts with "/wp-admin" OR URI Path starts with "/wp-login"
→ Bypass cache

এটি আগে করুন। অ্যাডমিন সেশন ক্যাশ করা মানে এক লগইন করা ব্যবহারকারীর পেজ আরেকজনকে দেখানো।

নিয়ম ২ — আপলোড শক্ত করে ক্যাশ করুন। ছবি তো বদলায় না:

text

URI Path starts with "/wp-content/uploads"
→ Cache eligible, Edge TTL 1 month

WooCommerce চালালে নিয়ম ১-এ /cart, /checkout ও /my-account যোগ করুন। ক্যাশ করা কার্ট দেখানো এমন একটা বাগ, যা ধরা পড়তে এক সপ্তাহ লাগে আর ব্যাখ্যা করতে অনেকক্ষণ।

WordPress সাইটে গোটা সাইটজুড়ে "Cache Everything" চালু করবেন না, যদি না লগইন করা ব্যবহারকারীদের জন্য কুকি-সচেতন বাইপাস নিয়ম বসিয়ে থাকেন। এটি সত্যিকারের একটি অপ্টিমাইজেশন, আর এভাবেই মানুষ ভুল করে ইন্টারনেটের প্রতিটি ভিজিটরকে লগইন করা হেডার দেখিয়ে বসে।

ধাপ ৫ — নিরাপত্তা, হালকা হাতে

ডিফল্টগুলো যুক্তিসঙ্গত। তিনটি জিনিস চালু করার মতো:

Bot Fight Mode — চালু। আপনার প্যাকেজের প্রসেস লিমিটে পৌঁছানোর আগেই এটি অবাক করার মতো পরিমাণ বাজে ট্র্যাফিক শুষে নেয়।
Security Level — Medium। High আসল মানুষকেও চ্যালেঞ্জ করে।
লগইন পেজে একটি রেট-লিমিটিং নিয়ম। /wp-login.php ইন্টারনেটের সবচেয়ে বেশি আক্রান্ত URL, আর এটি ব্রুট-ফোর্স চেষ্টা এজেই থামায় — আপনি যে মেশিন অন্যদের সঙ্গে ভাগ করছেন সেখানে নয়।

সত্যিই আক্রমণের মুখে না থাকলে "Under Attack" মোড এড়িয়ে চলুন। এটি প্রতিটি ভিজিটরের সামনে একটি পর্দা বসায়, আর সার্চ ক্রলার সেটির জন্য অপেক্ষা করে না।

দ্বিতীয় ভুল: সার্ভার আর আসল ভিজিটর আইপি দেখে না

Cloudflare ট্র্যাফিক প্রক্সি করা শুরু করলে প্রতিটি রিকোয়েস্ট আপনার সার্ভারে পৌঁছায় একটি Cloudflare আইপি থেকে। ভিজিটর কে ছিলেন, সার্ভারের তা জানার উপায় থাকে না।

এর ফলগুলো সপ্তাহের পর সপ্তাহ ধরে একটা একটা করে সামনে আসে:

অ্যানালিটিক্সে সব ট্র্যাফিক দেখায় হাতেগোনা কয়েকটি আইপি থেকে।
সিকিউরিটি প্লাগইন Cloudflare-এর আইপি ব্যান করে — যাতে সবাই বাইরে ছিটকে যায়।
কমেন্ট স্প্যাম ফিল্টার কাজ করা বন্ধ করে।
রেট লিমিট ও জিও নিয়ম উদ্ভট আচরণ করে।

আসল আইপি থাকে CF-Connecting-IP হেডারে; সমাধান হলো সার্ভারকে সেটি পড়তে শেখানো। cPanel-এ সাধারণত এটি mod_cloudflare বা সমমানের কিছু — হোস্টকে জিজ্ঞেস করুন, বেশিরভাগেরই আছে। বিশেষ করে WordPress-এর ক্ষেত্রে অফিশিয়াল Cloudflare প্লাগইন এটি সামলায়, আর বেশিরভাগ সিকিউরিটি প্লাগইনে "সাইটটি Cloudflare-এর পেছনে" সেটিং থাকে, যা চালু করতেই হবে।

এটি সেটআপের সময়ই করুন — সিকিউরিটি প্লাগইন Cloudflare-কে ব্যান করে সাইট বন্ধ করে দেওয়ার পরে নয়।

Cloudflare যা ঠিক করে না

স্পষ্ট করে বলা দরকার, কারণ এটি এমন অনেক কিছুর দোষ ও কৃতিত্ব পায় যা এটি করে না:

ধীর অরিজিন ধীরই থাকে। Cloudflare অ্যাসেট ক্যাশ করে; ক্যাশ না হওয়া HTML পেজ এখনো আপনার সার্ভারই বানায়, যত গতিতে পারে। TTFB খারাপ হলে আগে সাইট ও হোস্ট ঠিক করুন।
এটি ব্যাকআপের বিকল্প নয়।
এটি হ্যাক হওয়া সাইট ঠিক করে না। বরং ম্যালওয়্যারটুকু এজ থেকে আগের চেয়ে দ্রুত পরিবেশন করবে।
সঠিক সার্ভার লোকেশনের বিকল্প এটি নয়। বাংলাদেশি অডিয়েন্সের জন্য আমাদেরগুলো ঢাকায় BDIX-সংযুক্ত সার্ভারে চলে — বাংলাদেশি ভিজিটরের জন্য এটাই ৩০ মিলিসেকেন্ড আর ৩০০ মিলিসেকেন্ডের পার্থক্য — Cloudflare-কে যে রিকোয়েস্টগুলো পার করে দিতেই হয়, তাদের প্রতিটির সময় অরিজিনের অবস্থানই ঠিক করে।

দশ মিনিটের যাচাই

নেমসার্ভার প্রোপাগেট হওয়ার পর:

bash

# Cloudflare কি সত্যিই সামনে আছে?
curl -sI https://yoursite.com/ | grep -i "server\|cf-cache-status"

# অ্যাসেট কি ক্যাশ হচ্ছে? দুবার চালান — দ্বিতীয়বারে HIT আসা উচিত।
curl -sI https://yoursite.com/wp-content/uploads/example.jpg | grep -i cf-cache-status

তারপর হাতে হাতে: লগআউট অবস্থায় সাইট লোড করুন, অ্যাডমিনে ঢুকে স্বাভাবিক আচরণ নিশ্চিত করুন, সাইটের কনট্যাক্ট ফর্ম থেকে নিজেকে একটি ইমেইল পাঠান, আর দেখুন প্রকাশ করা কোনো পোস্ট ক্যাশের মেয়াদ শেষ হওয়ার অপেক্ষা না করে সঙ্গে সঙ্গেই দেখা যাচ্ছে কি না।

ইমেইল পরীক্ষাটাই মানুষ বাদ দেয়, আর ডিএনএস ইমপোর্টে সবচেয়ে বেশি ভুল হয় মেইলেই।

সচরাচর জিজ্ঞাসা

ছোট সাইটের জন্য Cloudflare-এর ফ্রি প্যাকেজ কি যথেষ্ট? হ্যাঁ। ফ্রি প্যাকেজে সিডিএন, ডিএনএস, এসএসএল, DDoS প্রতিরোধ ও ফায়ারওয়াল নিয়ম সবই আছে। পেইড প্যাকেজে যোগ হয় ইমেজ অপ্টিমাইজেশন, বেশি পেজ রুল আর এসএলএ — সাধারণ ব্যবসায়িক সাইট বা ব্লগের এর কোনোটিই লাগে না।

Cloudflare কি আমার সাইট দ্রুত করবে? স্ট্যাটিক অ্যাসেট আর দূরের ভিজিটরদের জন্য, অনেকটাই। ক্যাশ না হওয়া পেজের প্রথম HTML-এর জন্য নিজে থেকে নয় — সেটি এখনো আপনার সার্ভারের কাজ। একে হোস্টিং-স্তরের ক্যাশিংয়ের ওপরের একটি স্তর ভাবুন, বিকল্প নয়।

Cloudflare চালু করার পর সাইট ভেঙে গেল কেন? প্রায় সবসময়ই এসএসএল মোড। Full (strict) করুন আর নিশ্চিত করুন সার্ভারে বৈধ সার্টিফিকেট আছে। দ্বিতীয় সবচেয়ে সাধারণ কারণ কোনো ডিএনএস রেকর্ড বাদ পড়া, সাধারণত MX — তাতে সাইট নয়, ইমেইল ভাঙে।

Cloudflare কি আমার সার্ভারের আইপি লুকিয়ে রাখে? প্রক্সি করা রেকর্ডের জন্য হ্যাঁ, আর এটি সত্যিকারের একটি নিরাপত্তা সুবিধা। কিন্তু প্রক্সি না করা কোনো সাবডোমেইন — মেইল রেকর্ড, পুরোনো একটি ftp এন্ট্রি, স্টেজিং সাইট — সেটি ফাঁস করে দেবে। প্রতিটি ধূসর-মেঘ রেকর্ড দেখে নিন।

সিডিএন না চাইলে কি শুধু Cloudflare-এর ডিএনএস ব্যবহার করা যায়? যায়। প্রতিটি রেকর্ড ধূসর মেঘে রাখলে প্রক্সি ছাড়াই দ্রুত, ফ্রি ও সহজ ডিএনএস পাবেন। এটি যুক্তিসঙ্গত একটি সেটআপ, আর পরে চাইলে একেকটি রেকর্ড কমলা করে নিতে পারবেন।

cPanel হোস্টিংয়ের সঙ্গে Cloudflare কাজ করে? হ্যাঁ, আর এটাই সবচেয়ে প্রচলিত সমন্বয়। অরিজিন সার্টিফিকেটের জন্য সার্ভারে AutoSSL চালু রাখুন — Full (strict)-এর জন্য সেটি লাগবেই।

শেয়ার্ড হোস্টিংয়ে Cloudflare সেটআপ করবেন যেভাবে