غیرفعال کردن ECH برای حل مشکل باز نشدن سایت بعد از استفاده از کلودفلر

آبان ۱۴۰۵ وقتی پروکسی کلادفلر را برای فروشگاه زیپودو روشن کردیم، چند ساعت بعد پیام‌ها رسید: «سایت باز نمی‌شود» و «کروم خطای Connection Reset می‌دهد».

عجیب اینجا بود که همان لحظه از ترمینال همان سیستم، با اینترنت ایران و بدون VPN، صفحه در کمتر از یک ثانیه بالا می‌آمد.

علت، قابلیتی به نام Encrypted Client Hello بود که کلادفلر روی همه‌ی دامنه‌های پلن رایگان به‌صورت پیش‌فرض روشن می‌کند.

راه‌حل هم غیرفعال کردن ECH کلادفلر بود؛ کاری که در داشبورد دکمه‌ای برایش وجود ندارد و فقط با یک درخواست API انجام می‌شود.

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

ECH چیست و چرا کلادفلر آن را روی سایت شما روشن کرده است؟

هر بار که مرورگر به یک سایت HTTPS وصل می‌شود، قبل از هر چیز پیامی به نام ClientHello می‌فرستد. در این پیام، نام دامنه‌ای که کاربر می‌خواهد باز کند در فیلدی به نام SNI و به‌صورت متن ساده نوشته می‌شود. یعنی با اینکه محتوای صفحه رمزنگاری شده، هر واسطه‌ای در مسیر، از اپراتور اینترنت گرفته تا سیستم فیلترینگ، می‌تواند ببیند کاربر سراغ چه دامنه‌ای رفته است.

Encrypted Client Hello یا به اختصار ECH این نشتی را می‌بندد. طبق مستندات رسمی کلادفلر، این قابلیت بخشی از دست‌دادن TLS را رمز می‌کند و نام واقعی سایت را پنهان می‌کند. واسطه‌ها فقط می‌فهمند کاربر به «یکی از سایت‌های کلادفلر» وصل شده، نه به کدام‌یک. کلادفلر ECH را برای دامنه‌های پلن رایگان به‌صورت پیش‌فرض فعال کرده و صاحب سایت معمولاً حتی خبر ندارد چنین چیزی روشن است.

ECH دقیقاً چه چیزی را رمز می‌کند؟

در ECH مرورگر دو ClientHello می‌سازد:

  • ClientHello بیرونی: به‌صورت متن ساده فرستاده می‌شود و در SNI آن به‌جای دامنه‌ی شما، نام مشترک cloudflare-ech.com نوشته شده است. همه‌ی سایت‌های کلادفلر که ECH دارند همین نام را نشان می‌دهند.
  • ClientHello درونی: نام واقعی دامنه و تنظیمات اصلی اتصال را دارد و با کلید عمومی‌ای رمز می‌شود که فقط کلادفلر می‌تواند بازش کند.

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

کلید ECH از کجا به مرورگر می‌رسد؟

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

یک نکته‌ی مهم دیگر: ECH فقط روی رکوردهایی اعمال می‌شود که پروکسی کلادفلر برایشان روشن است (ابر نارنجی). رکوردهای DNS Only مستقیم به سرور خودتان وصل می‌شوند و ECH رویشان اثری ندارد. برای همین خیلی‌ها دقیقاً بعد از روشن کردن پروکسی، مثلاً برای استفاده از Google Tag Gateway یا کش کلادفلر، با این مشکل روبه‌رو می‌شوند.

این مشکل معمولاً بعد از چه تغییری شروع می‌شود؟

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

  1. ظهر روز اول: برای اینکه اسکریپت گوگل تگ منیجر از دامنه‌ی خود سایت لود شود و کمتر توسط ادبلاکرها مسدود شود، قابلیت Google Tag Gateway کلادفلر را فعال کردیم. این قابلیت فقط روی رکوردهای پروکسی‌شده کار می‌کند، پس همه‌ی رکوردهای اصلی را Proxied کردیم.
  2. یکی دو ساعت بعد: گزارش اول از یک همکار رسید که سایت روی لپ‌تاپش باز نمی‌شود. روی گوشی همان شخص، با یک مرورگر دیگر، سایت باز می‌شد. همین تفاوت اولین سرنخ بود.
  3. ساعت بعد: لاگ تغییرات حساب کلادفلر (بخش Audit Logs) را بررسی کردیم و دیدیم تنها تغییر آن روز همان روشن کردن پروکسی بوده است. با دستور trace هم مشخص شد مرورگرها با sni=encrypted وصل می‌شوند.
  4. بعد از خاموش کردن ECH: چند دقیقه طول کشید تا کش DNS مرورگرها خالی شود. بعد از آن، دسترسی از اینترنت ثابت و همراه پایدار شد.

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

چرا ECH در ایران باعث خطای Connection Reset می‌شود؟

اینجا باید دقیق باشیم، چون منابع معتبر درباره‌ی ایران هنوز کم‌اند.

رفتار روسیه کاملاً مستند است. پژوهش Niere و همکاران در کنفرانس FOCI 2025 نشان می‌دهد تجهیزات فیلترینگ روسیه هر ClientHello را که هم افزونه‌ی ECH و هم SNI بیرونی cloudflare-ech.com را داشته باشد دور می‌ریزند. برای ایران، همان پژوهش می‌گوید در زمان اندازه‌گیری، پیام ECH مستقیماً مسدود نمی‌شد و ایران از راه دیگری جلوی ECH را می‌گرفت: با مسدود کردن سرویس‌های DNS رمزنگاری‌شده که کلید ECH را به مرورگر می‌رسانند. از طرف دیگر، گزارش OONI از سال ۲۰۲۰ نشان داده که فیلترینگ ایران اتصال TLS را بر اساس SNI و با فرستادن بسته‌ی TCP RST قطع می‌کند. این بسته همان چیزی است که در کروم به شکل خطای ERR_CONNECTION_RESET دیده می‌شود.

بیشتر بخوانید:  راهنمای قدم به قدم سئوی وب سایت: از بهینه‌سازی تصاویر تا استفاده از تگ‌های مناسب

تجربه‌ی ما با این تصویر جور درمی‌آمد:

  • از کروم، صفحه‌ی اصلی چند بار پشت سر هم اصلاً باز نشد و یک بار هم بعد از هفت ثانیه انتظار، نیمه‌کاره ماند.
  • از همان سیستم با curl، که اصلاً از ECH پشتیبانی نمی‌کند، ۲۰ درخواست از ۲۰ درخواست با موفقیت و در حدود ۰٫۸ ثانیه جواب گرفت.
  • سایت خود کلادفلر (www.cloudflare.com) که ECH ندارد، در همان کروم بدون مشکل باز می‌شد.
  • بعد از خاموش کردن ECH و پاک کردن کش DNS کروم، زمان رسیدن اولین بایت به حدود ۱٫۲ ثانیه و بارگذاری کامل به حدود ۱٫۶ ثانیه رسید.

پس با اینکه هنوز گزارش رسمی‌ای نمی‌گوید ایران دقیقاً چه قاعده‌ای روی ECH اعمال می‌کند، در عمل ترافیک ECH از اینترنت ایران ناپایدار است. سیاست‌های فیلترینگ هم مدام عوض می‌شوند. برای یک سایت فروشگاهی که مشتری‌اش داخل ایران است، این ریسک ارزش نگه داشتن ECH را ندارد.

از کجا بفهمم مشکل سایتم واقعاً ECH است؟

قبل از تغییر هر تنظیمی، مطمئن شوید با همین مشکل طرف هستید. خطای Connection Reset علت‌های دیگری هم دارد و اگر علت چیز دیگری باشد، خاموش کردن ECH وقتتان را هدر می‌دهد. این چهار تست را به ترتیب انجام دهید:

  1. تست trace کلادفلر: در مرورگری که سایت در آن باز می‌شود (مثلاً با VPN)، نشانی https://دامنه‌ی-شما/cdn-cgi/trace را باز کنید. اگر در خروجی خط sni=encrypted را دیدید، ECH روی دامنه‌ی شما فعال است و مرورگر از آن استفاده می‌کند. sni=plaintext یعنی اتصال بدون ECH برقرار شده است.
  2. مقایسه‌ی curl و کروم: در ترمینال دستور curl -I https://دامنه‌ی-شما/ را بدون VPN اجرا کنید. اگر curl کد ۲۰۰ می‌گیرد ولی کروم روی همان شبکه خطای Reset می‌دهد، تفاوت در نوع دست‌دادن TLS است و ECH مظنون اصلی است.
  3. مقایسه با یک سایت کلادفلری بدون ECH: اگر www.cloudflare.com بدون مشکل باز می‌شود ولی سایت شما نه، مشکل از کل IPهای کلادفلر نیست.
  4. تست با مرورگرهای مختلف: اگر فایرفاکس با DNS سیستم سایت را باز می‌کند ولی کروم با DNS امن (Secure DNS) باز نمی‌کند، باز هم ردپای رکورد HTTPS و ECH را می‌بینید.

این جدول کمک می‌کند علامت‌ها را کنار هم بگذارید:

علامت ECH فیلتر شدن IP کلادفلر مشکل سرور اصلی
curl جواب می‌دهد ولی کروم Reset می‌شود محتمل بعید بعید
هیچ سایت کلادفلری بدون VPN باز نمی‌شود بعید محتمل بعید
خطای ۵۲۰ تا ۵۲۴ با صفحه‌ی کلادفلر بعید بعید محتمل
مشکل فقط بعد از روشن کردن پروکسی شروع شد محتمل محتمل بعید
با VPN همه‌چیز درست است محتمل محتمل بعید

کدام کاربران و مرورگرها درگیر این مشکل می‌شوند؟

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

  • مرورگر: کروم، اج و بقیه‌ی مرورگرهای مبتنی بر کرومیوم، و همچنین فایرفاکس، از ECH پشتیبانی می‌کنند. ابزارهای خط فرمان مثل curl و بسیاری از کتابخانه‌های برنامه‌نویسی هنوز ECH ندارند. برای همین درخواست‌های سمت سرور، ربات‌ها و ابزارهای مانیتورینگ معمولاً هیچ خطایی گزارش نمی‌کنند.
  • DNS کاربر: مرورگر فقط وقتی ECH را به کار می‌گیرد که رکورد HTTPS دامنه را دریافت کند. اگر DNS اپراتور یا مودم کاربر این نوع رکورد را برنگرداند، اتصال عادی و بدون ECH برقرار می‌شود و کاربر مشکلی نمی‌بیند. اگر کاربر در مرورگرش DNS امن را روشن کرده باشد یا DNS سیستمش رکورد HTTPS را برگرداند، ECH فعال می‌شود.
  • کش مرورگر: کروم پاسخ‌های DNS را مدتی نگه می‌دارد. کاربری که یک بار رکورد HTTPS را گرفته، تا وقتی آن کش منقضی نشده با ECH وصل می‌شود. حتی بعد از خاموش کردن ECH هم چند دقیقه طول می‌کشد تا رفتارش عوض شود.

نتیجه‌ی عملی این است که نباید به تست خودتان بسنده کنید. ابزارهای مانیتورینگ آپتایم هم معمولاً ECH ندارند و تا وقتی سرور جواب بدهد، سایت را سالم نشان می‌دهند. معیار درست، تست با کروم و بدون VPN روی چند اپراتور مختلف است.

چرا گزینه‌ی ECH در داشبورد کلادفلر پیدا نمی‌شود؟

مستندات کلادفلر از تنظیمی به نام Encrypted ClientHello در صفحه‌ی SSL/TLS و بخش Edge Certificates صحبت می‌کند. اما اگر دامنه‌تان روی پلن رایگان باشد، احتمالاً این گزینه را آنجا نمی‌بینید. ما هم صفحه‌ی Edge Certificates دامنه‌ی رایگان‌مان را خط به خط گشتیم: گزینه‌هایی مثل Always Use HTTPS، TLS 1.3 و Minimum TLS Version بودند، اما اثری از ECH نبود. کاربران راهنماهای روسی هم که در سال ۲۰۲۴ با همین مشکل درگیر شدند همین را گزارش کرده‌اند.

بیشتر بخوانید:  سئوی وب سایت: چگونه با استفاده از شبکه‌های اجتماعی، ترافیک سایت را افزایش دهیم؟

با این حال، خود تنظیم در API کلادفلر وجود دارد و روی پلن رایگان هم قابل ویرایش است. پاسخ API برای این تنظیم صریحاً "editable": true برمی‌گرداند. پس تنها راه، یک درخواست مستقیم به API است. این کار سخت نیست و با یک دستور تمام می‌شود.

آموزش غیرفعال کردن ECH کلادفلر قدم‌به‌قدم

برای این کار سه چیز لازم دارید: شناسه‌ی دامنه (Zone ID)، یک توکن API با دسترسی محدود، و یک ترمینال. در ویندوز PowerShell کافی است و در مک و لینوکس Terminal.

قدم اول: پیدا کردن Zone ID

  1. وارد داشبورد کلادفلر شوید و دامنه‌ی موردنظر را انتخاب کنید.
  2. در صفحه‌ی Overview دامنه، پایین ستون سمت راست، بخشی به نام API هست.
  3. مقدار Zone ID را کپی کنید. یک رشته‌ی ۳۲ کاراکتری از حروف و اعداد است.

قدم دوم: ساخت توکن API با کمترین دسترسی

خیلی از راهنماهای اینترنتی برای این کار از Global API Key استفاده می‌کنند. این کلید به کل حساب کلادفلر شما دسترسی کامل دارد و اگر جایی لو برود، همه‌ی دامنه‌ها و تنظیمات‌تان در خطر است. توکنی بسازید که فقط همین یک کار را بتواند انجام دهد:

  1. از منوی پروفایل (آیکون کاربر بالای صفحه) وارد My Profile و بعد API Tokens شوید.
  2. روی Create Token بزنید و پایین صفحه گزینه‌ی Create Custom Token را انتخاب کنید.
  3. در بخش Permissions این سه مقدار را انتخاب کنید: Zone ، Zone Settings ، Edit.
  4. در بخش Zone Resources گزینه‌ی Include و بعد Specific zone را بزنید و فقط دامنه‌ی خودتان را انتخاب کنید.
  5. اگر می‌خواهید محتاط‌تر باشید، در بخش TTL تاریخ انقضای توکن را همین امروز بگذارید.
  6. توکن را بسازید و همان لحظه کپی کنید. کلادفلر فقط یک بار نشانش می‌دهد.

قدم سوم: بررسی وضعیت فعلی ECH

قبل از تغییر، ببینید ECH الان روشن است یا نه. در دستورهای زیر ZONE_ID و API_TOKEN را با مقدارهای خودتان جایگزین کنید:

curl "https://api.cloudflare.com/client/v4/zones/ZONE_ID/settings/ech" -H "Authorization: Bearer API_TOKEN"

اگر در پاسخ "value":"on" را دیدید، ECH فعال است و ادامه بدهید.

قدم چهارم: اجرای دستور غیرفعال‌سازی

در مک، لینوکس یا Git Bash ویندوز:

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/ZONE_ID/settings/ech" -H "Authorization: Bearer API_TOKEN" -H "Content-Type: application/json" --data '{"value":"off"}'

در PowerShell ویندوز، نقل‌قول‌های داخل دستور curl گاهی خراب می‌شوند. برای همین بهتر است از دستور داخلی خود PowerShell استفاده کنید:

Invoke-RestMethod -Method Patch -Uri "https://api.cloudflare.com/client/v4/zones/ZONE_ID/settings/ech" -Headers @{Authorization="Bearer API_TOKEN"} -ContentType "application/json" -Body '{"value":"off"}'

پاسخ موفق شامل "success":true و "value":"off" است. اگر خطای 403 یا Authentication error گرفتید، دسترسی توکن را دوباره چک کنید. معمولاً Zone Settings به‌جای Edit روی Read مانده یا دامنه‌ی اشتباهی انتخاب شده است.

بعد از غیرفعال کردن ECH کلادفلر چطور مطمئن شوم مشکل حل شده؟

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

  1. در کروم نشانی chrome://net-internals/#dns را باز کنید و روی Clear host cache بزنید.
  2. در همان صفحه، از بخش Sockets گزینه‌ی Flush socket pools را بزنید تا اتصال‌های باز قبلی بسته شوند.
  3. نشانی https://دامنه‌ی-شما/cdn-cgi/trace را دوباره باز کنید. باید sni=plaintext ببینید.
  4. بدون VPN صفحه‌ی اصلی و چند صفحه‌ی داخلی سایت را باز کنید. در ابزار توسعه‌دهنده‌ی کروم (کلید F12)، تب Network، زمان TTFB درخواست اول را ببینید.
  5. اگر کاربران دیگری مشکل را گزارش داده بودند، از آن‌ها بخواهید مرورگرشان را کامل ببندند و دوباره باز کنند.

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

غیرفعال کردن ECH چه چیزی را از دست می‌دهد؟

صادقانه بگوییم: با خاموش کردن ECH، نام دامنه‌ی شما دوباره در SNI و به‌صورت متن ساده دیده می‌شود. این تنها چیزی است که از دست می‌دهید. ببینیم چه چیزهایی دست‌نخورده می‌مانند:

موضوع با ECH بدون ECH
رمزنگاری محتوای صفحه، فرم‌ها و رمزهای عبور کامل (TLS 1.3) کامل (TLS 1.3)
دیده شدن نام دامنه در مسیر پنهان قابل مشاهده
پایداری دسترسی از اینترنت ایران ناپایدار پایدار، مثل بقیه‌ی سایت‌های کلادفلر
اثر روی سئو و خزش گوگل ندارد ندارد
گواهی SSL و قفل سبز مرورگر بدون تغییر بدون تغییر

نام دامنه‌ی شما قبلاً هم از راه‌های دیگری، مثل درخواست DNS کاربر، برای اپراتور قابل دیدن بود. برای یک سایت وردپرسی که مخاطبش داخل ایران است، دسترسی پایدار خیلی مهم‌تر از پنهان ماندن نام دامنه در SNI است.

اگر بعد از خاموش کردن ECH هنوز سایت باز نمی‌شود چه کنم؟

اگر sni=plaintext را می‌بینید ولی کاربران هنوز خطا می‌گیرند، علت جای دیگری است. این موارد را به ترتیب بررسی کنید:

  • فیلتر شدن یا محدودیت IPهای کلادفلر: گاهی بخشی از رنج IP کلادفلر روی بعضی اپراتورها کند یا قطع می‌شود. اگر سایت‌های دیگر کلادفلری هم روی همان اینترنت باز نمی‌شوند، تنها راه قطعی برگرداندن رکوردها به حالت DNS Only است. با این کار قابلیت‌هایی که به پروکسی نیاز دارند، مثل کش لبه، WAF و Google Tag Gateway، از کار می‌افتند.
  • HTTP/3 و QUIC: اپراتورهای ایرانی با ترافیک QUIC رفتار یکسانی ندارند. مرورگرها معمولاً خودشان به HTTP/2 برمی‌گردند، اما اگر کندی اولین بارگذاری زیاد است، خاموش کردن HTTP/3 از تب Speed و بخش Settings را هم امتحان کنید.
  • IPv6: اگر بخشی از کاربران روی اینترنت همراه با IPv6 مشکل دارند، رفتار رکورد AAAA را جداگانه تست کنید.
  • کندی سرور اصلی: اگر صفحه باز می‌شود ولی اولین بایت چند ثانیه طول می‌کشد، مشکل از هاست یا وردپرس است، نه از کلادفلر. افزونه‌های سنگین، کش غیرفعال یا درخواست‌های بیرونی کند در قالب را بررسی کنید.
بیشتر بخوانید:  تاثیر الگوریتم‌های هوشمند بر تحلیل کلمات کلیدی

چک‌لیست نهایی برای سایت وردپرسی پشت کلادفلر

وقتی پروکسی کلادفلر را برای اولین بار روشن می‌کنید، این موارد را هم کنار ECH چک کنید. بیشترشان را از اشتباه‌های خودمان یاد گرفتیم:

  • رکوردهای مربوط به ایمیل، مثل mail، باید DNS Only بمانند. پروکسی کلادفلر فقط ترافیک وب را عبور می‌دهد و اگر نرم‌افزار ایمیل با این آدرس وصل شود، ارسال و دریافت قطع می‌شود.
  • حالت SSL/TLS را روی Full (strict) بگذارید. حالت Flexible در وردپرس معمولاً به حلقه‌ی ریدایرکت و خطای Too many redirects ختم می‌شود.
  • اگر از افزونه‌ای استفاده می‌کنید که خودش HTTP را به HTTPS ریدایرکت می‌کند، Always Use HTTPS کلادفلر را با احتیاط روشن کنید تا ریدایرکت دوبار انجام نشود.
  • بعد از هر تغییر مهم، سایت را از چند اپراتور مختلف و بدون VPN تست کنید: اینترنت ثابت، همراه اول و ایرانسل.
  • توکن‌های API موقت را بعد از کار حذف کنید.

اگر هنوز سؤالی دارید، احتمالاً جوابش در پرسش‌های پرتکرار پایین هست. این سؤال‌ها را از جستجوهای واقعی مدیران سایت درباره‌ی ECH و خطای Connection Reset جمع کرده‌ایم.

پرسش‌های پرتکرار درباره‌ی ECH کلادفلر

آیا غیرفعال کردن ECH روی سئو یا امنیت سایت اثر منفی دارد؟

روی سئو هیچ اثری ندارد. گوگل‌بات و بقیه‌ی خزنده‌ها اصلاً به ECH وابسته نیستند و رتبه‌بندی بر اساس آن انجام نمی‌شود. از نظر امنیت هم رمزنگاری محتوای صفحه، فرم‌ها و رمزهای عبور با TLS 1.3 دقیقاً مثل قبل باقی می‌ماند. تنها تفاوت این است که نام دامنه‌ی شما در ابتدای اتصال قابل دیدن می‌شود؛ همان وضعیتی که بیشتر سایت‌های اینترنت دارند.

چرا سایت با VPN باز می‌شود ولی بدون VPN خطای Connection Reset می‌دهد؟

وقتی VPN روشن است، ترافیک شما از مسیر فیلترینگ داخلی عبور نمی‌کند و اتصال ECH بدون دخالت برقرار می‌شود. بدون VPN، تجهیزات فیلترینگ در مسیر اتصال را می‌بینند و ممکن است با یک بسته‌ی TCP RST قطعش کنند. کروم این قطعی را با پیام ERR_CONNECTION_RESET نشان می‌دهد. اگر سایت‌های دیگر کلادفلر بدون VPN باز می‌شوند و فقط سایت شما مشکل دارد، احتمال اینکه علت ECH باشد زیاد است.

در پلن رایگان کلادفلر گزینه‌ی Encrypted ClientHello کجاست؟

در پلن رایگان این گزینه معمولاً در داشبورد نمایش داده نمی‌شود، با اینکه ECH به‌صورت پیش‌فرض روشن است. خود تنظیم در API کلادفلر وجود دارد و قابل ویرایش است. برای خاموش کردنش یک توکن API با دسترسی Zone Settings Edit بسازید و یک درخواست PATCH به نشانی settings/ech دامنه بفرستید. دستور آماده‌اش در متن همین مقاله آمده است.

آیا می‌توانم به‌جای توکن از Global API Key استفاده کنم؟

از نظر فنی بله، دستور با Global API Key هم کار می‌کند. اما این کلید به همه‌ی دامنه‌ها، تنظیمات DNS و حتی اطلاعات صورت‌حساب حساب کلادفلرتان دسترسی کامل دارد. اگر در تاریخچه‌ی ترمینال یا یک اسکرین‌شات لو برود، خسارتش خیلی بیشتر از یک توکن محدود است. توکنی بسازید که فقط به Zone Settings همان یک دامنه دسترسی داشته باشد و بعد از کار حذفش کنید.

بعد از اجرای دستور چقدر طول می‌کشد تا تغییر اعمال شود؟

در سمت کلادفلر تغییر تقریباً فوری است. اما مرورگرها و DNS کاربران رکورد HTTPS قبلی را چند دقیقه در کش نگه می‌دارند. در تجربه‌ی ما بعد از حدود پنج تا ده دقیقه و پاک کردن کش DNS کروم، اتصال پایدار شد. برای کاربرانی که دسترسی فنی ندارند، بستن کامل مرورگر و باز کردن دوباره‌اش معمولاً کافی است.

اگر بخواهم ECH را دوباره روشن کنم چه کار کنم؟

همان دستور PATCH را با مقدار on به‌جای off اجرا کنید. هیچ تنظیم دیگری از دامنه‌تان تغییر نمی‌کند و ECH مثل قبل فعال می‌شود. اگر روزی شرایط شبکه تغییر کرد و خواستید دوباره امتحانش کنید، بهتر است بعد از روشن کردن، دسترسی سایت را چند روز از اپراتورهای مختلف زیر نظر داشته باشید.

آیا HTTP/3 کلادفلر هم باید برای کاربران ایرانی خاموش شود؟

لزوماً نه. مرورگرها وقتی HTTP/3 جواب ندهد، خودشان به HTTP/2 برمی‌گردند و سایت باز می‌شود. اما این برگشت ممکن است چند صد میلی‌ثانیه به اولین بارگذاری اضافه کند. اگر بعد از خاموش کردن ECH هنوز اولین بازدید کند است، HTTP/3 را آزمایشی از بخش Speed خاموش کنید و زمان TTFB را قبل و بعد مقایسه کنید.

دیدگاهتان را بنویسید

مطالب مرتبط