کلودفلر برای سایت ایرانی؛ کجا کمک می‌کند و کجا دردسر دارد

پاسخ کوتاه به پرسش کلودفلر برای سایت ایرانی این است: بستگی دارد بازدیدکننده‌های شما از کدام شبکه می‌آیند. مخاطب داخلی روی سرور تهران یعنی یک گام شبکه و یک TLS handshake اضافه؛ مخاطب بیرون کشور یا فشار ربات یعنی همان لایه ارزش دارد. تصمیم را با اندازه‌گیری از اتصال خودتان بگیرید، نه با توصیه کلی.

موضوع	حالت Proxied (ابر نارنجی)	حالت DNS Only (ابر خاکستری)
پاسخ رکورد A در DNS	یکی از IP های انی‌کست کلودفلر	آدرس IP واقعی سرور شما
مسیر درخواست HTTP	از شبکه کلودفلر به سرور	مستقیم از کاربر به سرور
دسترسی مستقیم به مبدأ	تا ۸۰ و ۴۴۳ را به رنج کلودفلر محدود نکنید، باز است	باز است
کش و دفاع DDoS لبه	فعال؛ قاعده‌های WAF به طرح شما بستگی دارد	هیچ‌کدام اعمال نمی‌شود
آدرس IP بازدیدکننده در لاگ سرور	از هدر CF-Connecting-IP خوانده می‌شود	همان IP کاربر ثبت می‌شود
مقدار TTL رکورد	ثابت روی ۳۰۰ ثانیه	خودتان تعیین می‌کنید

این یک انتخاب دوگانه ساده نیست. سه متغیر در آن دخالت دارند: مخاطب سایت، مسیر شبکه او تا سرور، و رفتار اپلیکیشن در برابر کش و IP کاربر. پس اول روشن می‌کنیم هر حالت چه چیزی را عوض می‌کند، بعد فرمان‌های آزمایش را می‌دهیم و آخر با یک جدول تصمیم می‌گیرید.

کلودفلر روی سرور داخلی دقیقاً چه چیزی را عوض می‌کند

روشن کردن ابر نارنجی سه چیز را عوض می‌کند: پاسخ DNS دامنه، مسیر درخواست HTTP و اینکه درخواست اول به کدام لایه می‌رسد. تا وقتی رکورد DNS Only است، ترافیک وب از شبکه کلودفلر عبور نمی‌کند.

طبق مستندات رسمی وضعیت پروکسی (آوریل ۲۰۲۶)، رکورد پروکسی‌شده ترافیک HTTP و HTTPS را از شبکه کلودفلر عبور می‌دهد و همین امکان کش و قاعده‌های امنیتی لبه را می‌سازد. رکورد DNS Only هم IP سرور را به هر پرس‌وجوکننده‌ای نشان می‌دهد. پس دستاورد مستقیم کلودفلر برای سایت ایرانی بیرون رفتن IP سرور از پاسخ DNS است؛ این با از دسترس خارج شدن سرور یکی نیست.

حالت Proxied در برابر DNS Only؛ تفاوت در لایه رکورد

فقط سه نوع رکورد قابل پروکسی شدن هستند: A، AAAA و CNAME؛ MX و TXT همیشه DNS Only می‌مانند. رکورد پروکسی‌شده TTL ثابت ۳۰۰ ثانیه می‌گیرد و اگر سرور در بازه Proxy Read Timeout پاسخ ندهد، خطای ۵۲۴ می‌آید.

پنهان شدن IP بدون بستن مبدأ، پنهان‌سازی نیست

مستندات کلودفلر صریح است: هر کسی IP سرور را پیدا کند می‌تواند مستقیم درخواست بفرستد و از همه محافظت‌ها عبور کند. راهنمای محافظت از سرور مبدأ قدم لازم را می‌گوید: ترافیکی که از رنج‌های IP کلودفلر نمی‌آید باید روی سرور بسته شود. فهرست رسمی این رنج‌ها در صفحه IP های کلودفلر است و تغییر می‌کند، پس فرمان زیر آن را در لحظه می‌خواند.

# فقط رنج‌های رسمی کلودفلر به پورت 80 و 443 دسترسی داشته باشند
for net in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  ufw allow proto tcp from "$net" to any port 80,443
done
ufw deny 80/tcp && ufw deny 443/tcp

آزمون این ادعا یک فرمان است: درخواست را با نام دامنه اما روی IP سرور بفرستید؛ پاسخ ۲۰۰ یعنی مبدأ باز مانده.

curl -I --max-time 10 --resolve www.example.ir:443:ORIGIN_IP https://www.example.ir/

زیردامنه‌ای مثل mail که با همان IP به شکل DNS Only بماند هم سرور را لو می‌دهد. همان راهنما می‌گوید رکوردهای DNS Only را بازبینی و بعد از انتقال IP سرور را عوض کنید، چون رکوردهای تاریخی دامنه عمومی می‌مانند. مرور تغییر نیم‌سرور دامنه ترتیب کار را روشن می‌کند.

پورت‌های پروکسی‌شده و مرز طرح رایگان

پس پنل مدیریتی روی پورت غیر استاندارد باید به زیردامنه‌ای جدا با DNS Only برود. مرز طرح رایگان هم مهم است: Universal SSL و Always Use HTTPS و کش پیش‌فرض و AOP روی آن هستند. اما طبق جدول دسترسی مستندات WAF کلودفلر (سپتامبر ۲۰۲۶) تنها Free Managed Ruleset فعال است؛ قاعده‌های مدیریت‌شده کلودفلر و OWASP از Pro به بالا هستند. پس «پروکسی شدم، یعنی WAF دارم» درست نیست.

هزینه‌های پنهان یک لایه اضافه در مسیر کاربر داخلی

هر درخواست پروکسی‌شده یک گام شبکه و یک TLS handshake بیشتر دارد: کاربر با نزدیک‌ترین نقطه کلودفلر TLS برقرار می‌کند و کلودفلر اتصال دومی با سرور می‌سازد. هزینه دوم این است که اگر آن نقطه بیرون کشور باشد، ترافیک کاربر داخلی به مسیر بین‌الملل اپراتور وابسته می‌شود؛ مسیری بیرون از کنترل شما.

چرا پاسخ به شبکه بازدیدکننده بستگی دارد

نقطه پاسخ‌دهنده شبکه کلودفلر با مسیریابی انی‌کست انتخاب می‌شود و برای هر اپراتور می‌تواند متفاوت باشد. لازم نیست حدس بزنید: هدر cf-ray در انتهای مقدارش کد سه‌حرفی فرودگاهی همان نقطه را دارد، پس می‌بینید کاربر به کدام شهر وصل می‌شود. نتیجه استفاده از کلودفلر برای سایت ایرانی را همین داده تعیین می‌کند، نه قاعده کلی.

روش آزمایش از اتصال خودتان؛ سه فرمان کوتاه

اول ببینید رکوردهای A و AAAA به کجا اشاره می‌کنند: پاسخ یکی از IP های کلودفلر یعنی پروکسی‌شده، برگشتن IP سرور یعنی DNS Only. هدر cf-ray نشان می‌دهد پاسخ از لبه آمده و برای سنجش کش، cf-cache-status را با GET ببینید.

dig +short www.example.ir A
dig +short www.example.ir AAAA
curl -sD - -o /dev/null https://www.example.ir/ | grep -iE 'cf-ray|cf-cache-status'

یک نتیجه‌گیری اشتباه رایج را کنار بگذارید: مقدار DYNAMIC یا BYPASS یعنی پاسخ کش نشده، نه اینکه از لبه عبور نکرده. برای HTML همین طبیعی است و نشانه معتبر عبور از لبه، وجود cf-ray است.

گام دوم سنجیدن زمان است. چون time_appconnect تجمعی است، با time_connect می‌توانید سهم TLS را از سهم مسیر جدا کنید.

curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' https://www.example.ir/

گام سوم مقایسه است: یک زیردامنه آزمایشی را در هر دو حالت بسازید و فرمان را چند بار اجرا کنید. معیار تصمیم، اختلاف میانه دو حالت در برابر پراکندگی اجراهاست؛ اختلاف کوچک‌تر از نوسان معمول مسیر، تصمیمی را عوض نمی‌کند.

تنظیم SSL و کش بدون شکستن ورود کاربر و سبد خرید

دو تنظیم بیشترین خرابی را در کلودفلر برای سایت ایرانی می‌سازند: حالت رمزنگاری بین لبه و سرور، و قاعده کش. اولی سایت را در حلقه ریدایرکت می‌اندازد و دومی صفحه شخصی‌شده یک کاربر را به کاربر بعدی نشان می‌دهد.

انتخاب حالت رمزنگاری بین لبه و سرور

مستندات حالت‌های رمزنگاری (آوریل ۲۰۲۶) حالت پیش‌فرض را Automatic SSL/TLS معرفی می‌کند و پنج حالت دستی را کنارش می‌گذارد، با توصیه صریح به Full یا Full (strict). تفاوتشان اعتبارسنجی گواهی سرور است: در Full بررسی نمی‌شود، در Full (strict) باید معتبر و هم‌خوان با نام میزبان باشد.

حالت	اتصال لبه تا سرور	شرط سمت سرور
حالت Automatic SSL/TLS (پیش‌فرض)	کلودفلر امن‌ترین حالت ممکن را می‌گیرد	بسته به گواهی روی سرور
حالت Off	بدون رمزنگاری	توصیه نمی‌شود
حالت Flexible	اتصال HTTP بدون رمزنگاری	سرور نباید HTTP را به HTTPS ریدایرکت کند
حالت Full	اتصال HTTPS بدون بررسی گواهی	پورت 443 باز و گواهی، حتی خودامضا
حالت Full (strict)	اتصال HTTPS با بررسی گواهی	گواهی معتبر از CA عمومی یا Origin CA کلودفلر
حالت Strict (SSL-Only Origin Pull)	همیشه HTTPS با بررسی گواهی	مثل Full (strict)، فقط روی Enterprise

خطای ۵۲۵ یعنی TLS میان لبه و سرور شکل نگرفته؛ معمولاً پورت 443 بسته است، گواهی ندارید یا SNI پشتیبانی نمی‌شود. خطای ۵۲۶ یعنی گواهی شرط‌های Full (strict) را ندارد. هر دو را باید روی سرور حل کرد.

ریدایرکت HTTP به HTTPS را هم در لبه بگذارید، نه در سرور: گزینه Always Use HTTPS روی هر چهار طرح هست و مستنداتش توصیه می‌کند ریدایرکت را روی سرور نگذارید. برای محتوای ترکیبی گزینه جداگانه‌ای هست: Automatic HTTPS Rewrites ارجاع‌های ناامن داخل HTML را اصلاح می‌کند.

خطر کش شدن صفحه ورود و سبد خرید

کش پیش‌فرض بر پایه پسوند فایل کار می‌کند و HTML و JSON را کش نمی‌کند. سند رفتار پیش‌فرض کش (سپتامبر ۲۰۲۶) فهرست پسوندها را می‌دهد: css و js و jpg و png و webp و woff2 و pdf هستند و html نیست؛ robots.txt هم کش می‌شود. پس تا قاعده دستی نساخته‌اید، داشبورد کاربر کش نمی‌شود.

خطر از جایی شروع می‌شود که با یک Cache Rule مقدار Edge Cache TTL را روی HTML اعمال کنید، یا در وردپرس سراغ Cache Everything و APO بروید. همان سند می‌گوید این قاعده هدرهای پاسخ سرور را نادیده می‌گیرد؛ حتی Cache-Control با private یا Set-Cookie هم جلوی کش را نمی‌گیرد. نتیجه، نمایش سبد خرید یک نفر به نفر بعدی است.

• قاعده کش HTML را فقط روی مسیرهای عمومی اعمال کنید
• مسیرهای /cart و /checkout و /my-account و /wp-admin و /wp-login.php را بیرون بگذارید
• وجود کوکی نشست مثل wordpress_logged_in را شرط رد شدن از کش کنید
• هدر cf-cache-status را با کاربر مهمان و با کاربر وارد‌شده ببینید

# همان صفحه با کوکی نشست؛ مقدار HIT در پاسخ یعنی قاعده کش اشتباه است
curl -sD - -o /dev/null -b 'wordpress_logged_in_HASH=VALUE' https://www.example.ir/cart/ | grep -i cf-cache-status

در وردپرس اول تکلیف کش را روشن کنید و بعد لایه لبه را اضافه کنید؛ راهنمای فعال‌سازی CDN در وردپرس همین ترتیب را دارد.

آن‌چه در سرور شما می‌شکند و چه زمانی DNS Only انتخاب بهتری است

در کلودفلر برای سایت ایرانی سه چیز دیگر مثل قبل کار نمی‌کنند: IP کاربر در لاگ سرور، سرویس غیر وب روی پورت غیر استاندارد، و هر قاعده امنیتی که روی IP مبدأ تکیه دارد.

برگرداندن IP واقعی بازدیدکننده به سرور

با پروکسی شدن رکورد، لاگ سرور IP کلودفلر را ثبت می‌کند نه IP کاربر؛ آدرس واقعی در هدر CF-Connecting-IP می‌آید. راهنمای بازگرداندن IP اصلی بازدیدکننده (آوریل ۲۰۲۶) روش هر وب‌سرور را می‌دهد. در nginx این خطوط به بستر http در nginx.conf می‌روند و ماژول ngx_http_realip_module باید فعال باشد. خط set_real_ip_from را برای همه رنج‌های رسمی تکرار کنید.

# /etc/nginx/nginx.conf داخل بستر http
set_real_ip_from 103.21.244.0/22;   # برای هر رنج فهرست رسمی یک خط
set_real_ip_from 2400:cb00::/32;    # رنج‌های IPv6 را جا نگذارید
real_ip_header CF-Connecting-IP;

در آپاچی اول ماژول را در شل فعال کنید و بعد دایرکتیوها را در فایل کانفیگ بگذارید. این دو را مخلوط نکنید: a2enmod فرمان شل است و آپاچی با دیدن آن در کانفیگ بالا نمی‌آید.

sudo a2enmod remoteip && sudo systemctl reload apache2

# /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 2400:cb00::/32

در آپاچی مقدار %h در LogFormat را هم به %a عوض کنید. کلودفلر ماژول mod_remoteip را توصیه می‌کند و دیگر mod_cloudflare را نگه‌داری نمی‌کند.

رکوردهایی که باید DNS Only بمانند

رکورد MX همیشه DNS Only است و ایمیل از لبه عبور نمی‌کند. اشتباه رایج، ماندن رکورد A میزبان ایمیل روی همان IP سرور وب است؛ همان راهنمای محافظت از مبدأ توصیه می‌کند ایمیل و وب روی یک سرور نباشند.

• رکورد MX و SPF و DKIM و DMARC: همیشه DNS Only
• زیردامنه SSH و FTP و پنل مدیریت: DNS Only روی یک نام جدا
• رکورد تأیید مالکیت سرویس ثالث: DNS Only، چون پروکسی شدن تأیید را می‌شکند

جدول تصمیم بر اساس مخاطب سایت

جدول زیر انتخاب را بر پایه مخاطب می‌چیند، نه فهرست ویژگی؛ با نتایج اندازه‌گیری خودتان اصلاحش کنید.

مخاطب و شکل سایت	پیشنهاد نقطه شروع	دلیل
مخاطب داخلی، سایت محتوایی سبک	اول DNS Only را بسنجید	یک گام شبکه کمتر؛ HTML هم پیش‌فرض کش نمی‌شود
مخاطب داخلی، فشار ربات و اسکن	حالت Proxied با مبدأ بسته	فیلتر درخواست خودکار پیش از رسیدن به سرور
مخاطب بین‌المللی یا فارسی‌زبان خارج کشور	حالت Proxied را بسنجید	احتمال نزدیک‌تر بودن نقطه لبه؛ با cf-ray بسنجید
فروشگاه با ورود کاربر و سبد خرید	حالت Proxied با قاعده کش دقیق	خطر کش شدن صفحه شخصی‌شده
سرویس غیر وب روی همان دامنه	رکورد جدا با DNS Only	پورت‌های غیر استاندارد پروکسی نمی‌شوند

برگشت ساده است: وضعیت رکوردهای A و AAAA را به DNS Only عوض کنید؛ فقط چون TTL سیصد ثانیه است، تا چند دقیقه بخشی از ریزالورها پاسخ قبلی را می‌دهند.

پرسش‌هایی که پیش از تغییر وضعیت رکورد باید جوابشان را بدانید:

جمع‌بندی؛ تصمیم را روی داده خودتان بگیرید کلودفلر برای سایت ایرانی نه یک توصیه ثابت دارد و نه پاسخ بله و خیر. آن‌چه قطعی است، رفتار مستندشده خود سرویس است: رکورد پروکسی‌شده IP سرور را از پاسخ DNS بیرون می‌برد، TTL را روی ۳۰۰ ثانیه ثابت می‌کند، تنها روی فهرست مشخصی از پورت‌ها کار می‌کند و HTML را پیش‌فرض کش نمی‌کند. قطعی نیست اثر این لایه روی سرعت در شبکه مخاطب شما. پس ترتیب کار این است: اول پورت ۸۰ و ۴۴۳ را به رنج‌های رسمی کلودفلر محدود و رکوردهای DNS Only را بازبینی کنید، وگرنه پنهان‌سازی IP روی کاغذ می‌مانَد. بعد حالت رمزنگاری را روی Full یا Full (strict) ببرید. بعد IP واقعی بازدیدکننده را با realip یا mod_remoteip برگردانید، وگرنه لاگ و محدودسازی نرخ اشتباه کار می‌کند. در پایان هر دو حالت را از اتصال مخاطب هدف بسنجید؛ اگر نتیجه به سود لایه اضافه نبود، برگشت به DNS Only یک کلیک است.

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

منابع

• مستندات کلودفلر: وضعیت پروکسی رکوردهای DNS
• مستندات کلودفلر: محافظت از سرور مبدأ
• مستندات کلودفلر: حالت‌های رمزنگاری SSL/TLS
• مستندات کلودفلر: رفتار پیش‌فرض کش
• مستندات کلودفلر: بازگرداندن IP اصلی بازدیدکننده