رفع خطای ⁦err_quic_protocol_error⁩ در کروم و اج

در کروم یک ویدیو یا یک برنامه تحت وب را باز می‌کنید، بخشی از صفحه ظاهر می‌شود و سپس زبانه به صفحه‌ای خاکستری تبدیل می‌شود: عنوان «نمی‌توان به این سایت دست یافت» (در رابط انگلیسی ⁦"This site can’t be reached"⁩)، سطری که می‌گوید صفحه وب ممکن است «موقتاً خراب باشد یا ممکن است برای همیشه به آدرس وب جدید منتقل شده باشد» و در پایین صفحه ERR_QUIC_PROTOCOL_ERROR. بارگذاری دوباره گاهی کمک می‌کند و گاهی نه، و همین سایت در گوشی‌تان بی‌مشکل باز می‌شود.

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

خطای ERR_QUIC_PROTOCOL_ERROR یعنی چه؟#

QUIC یک پروتکل انتقال است: مجموعه قواعدی که داده‌های یک صفحه را میان سرور سایت و مرورگر شما جابه‌جا می‌کند. بیشتر ترافیک وب هنوز برای این کار از TCP استفاده می‌کند. QUIC همین کار را روی UDP انجام می‌دهد؛ پروتکلی ساده‌تر که بسته‌ها را بدون انتظار برای تأیید رسیدن هرکدام می‌فرستد. QUIC بررسی، ترتیب‌دهی و رمزگذاری را خودش اضافه می‌کند. تفاوت این دو پروتکل در تفاوت TCP و UDP توضیح داده شده است.

در فهرست خطاهای شبکه کرومیوم، کد منبعی که کروم و اج بر آن ساخته شده‌اند، این خطا شماره -356 است و در یک سطر توصیف شده است: ⁦"There is a QUIC protocol error."⁩ (یک خطای پروتکل QUIC وجود دارد). این کد می‌گوید اتصال QUIC شکست خورده است، نه اینکه چه کسی باعث آن شده است. صفحه خاکستری همان صفحه عمومی کروم است: کرومیوم برای این خطا متن ویژه‌ای ندارد، پس عبارت «موقتاً خراب» یک جمله پیش‌فرض است، نه تشخیص.

⁦HTTP/3⁩، QUIC و پورت ⁦UDP 443⁩ چه ارتباطی با هم دارند؟#

HTTP زبانی است که مرورگرها و سرورها برای درخواست‌ها و صفحه‌ها به کار می‌برند. جدیدترین نسخه آن، ⁦HTTP/3⁩، در ⁦RFC 9114⁩ به‌عنوان HTTP روی QUIC تعریف شده است و استاندارد QUIC، یعنی ⁦RFC 9000⁩، بسته‌های QUIC را درون دیتاگرام‌های UDP (تک‌بسته‌های UDP) قرار می‌دهد. برای یک آدرس https:// این معمولاً یعنی پورت 443 در UDP. سایت‌های امن همیشه از پورت 443 استفاده کرده‌اند، اما تا پیش از ⁦HTTP/3⁩ این یک پورت TCP بود و بسیاری از فایروال‌ها و فیلترها بر همین اساس ساخته شده‌اند.

سایت پشتیبانی از ⁦HTTP/3⁩ را در یکی از هدرهای یک پاسخ معمولی اعلام می‌کند. وقتی در 6 اکتبر 2026 بررسی کردیم، example.com با alt-svc: h3=":443"; ma=86400 پاسخ داد: ⁦HTTP/3⁩ (h3) روی پورت 443 در دسترس است و مرورگر می‌تواند این را 86,400 ثانیه، یعنی یک روز، به خاطر بسپارد. یوتیوب و گوگل همین پیشنهاد را با حافظه‌ای 30 روزه می‌فرستند.

استاندارد برای شکست هم برنامه دارد. وقتی شبکه‌ای UDP را مسدود می‌کند، ⁦RFC 9114⁩ می‌گوید مرورگرها باید به نسخه‌های مبتنی بر TCP از HTTP برگردند: ⁦HTTP/2⁩ یا ⁦HTTP/1.1⁩ روی یک اتصال رمزگذاری‌شده معمولی.

چرا کروم به جای برگشتن به اتصال معمولی خطا نشان می‌دهد؟#

کروم از این قاعده پیروی می‌کند، پس شبکه‌ای که QUIC را به‌طور کامل مسدود کند به‌ندرت این خطا را ایجاد می‌کند. خطا وقتی ظاهر می‌شود که QUIC ابتدا کار کند و بعد شکست بخورد:

1. سایت ⁦HTTP/3⁩ را پیشنهاد می‌دهد. این پیشنهاد در هدر alt-svc یا در برخی سایت‌ها در یک رکورد DNS می‌رسد و کروم آن را ذخیره می‌کند.
2. کروم QUIC را امتحان می‌کند. در بازدید بعدی یک اتصال QUIC به پورت 443 در UDP باز می‌کند و یک اتصال TCP معمولی را هم به‌عنوان پشتیبان آماده نگه می‌دارد.
3. QUIC هرگز وصل نمی‌شود. اگر بسته‌های UDP کاملاً مسدود باشند، TCP کار را به دست می‌گیرد و کروم QUIC را برای آن سایت چند دقیقه، و پس از شکست‌های پیاپی مدتی طولانی‌تر، خراب علامت می‌زند. شما چیزی متوجه نمی‌شوید.
4. QUIC وصل می‌شود، سپس پیش از رسیدن پاسخ قطع می‌شود. کروم درخواست را دوباره از طریق TCP می‌فرستد و اگر این کار جواب داد، QUIC را برای آن سایت خراب علامت می‌زند.
5. QUIC پس از شروع پاسخ قطع می‌شود. وقتی بخشی از پاسخ به مرورگر رسیده باشد، کد اتصال کرومیوم با آن درخواست مانند درخواستی رفتار می‌کند که ⁦"can not be retried"⁩ (نمی‌توان دوباره امتحانش کرد). کروم ERR_QUIC_PROTOCOL_ERROR را نشان می‌دهد.

پس این خطا به شبکه‌ای اشاره دارد که برای QUIC نیمه‌کاره کار می‌کند: بسته‌ها آن‌قدر عبور می‌کنند که یک صفحه شروع شود، سپس چیزی آن‌ها را دور می‌ریزد، تغییر می‌دهد یا قطع می‌کند. یک مسدودسازی تمیز فقط ⁦HTTP/3⁩ را از شما می‌گرفت، نه صفحه را.

علت‌های خطای ERR_QUIC_PROTOCOL_ERROR کدام‌اند؟#

در رایانه خانگی، برنامه‌های امنیتی نخستین مظنون‌اند. مرکز راهنمای ESET می‌گوید محافظت وب آن ممکن است وقتی QUIC روشن است درست کار نکند، و Trend Micro و WatchGuard مسدود کردن پورت 443 در UDP را مستند کرده‌اند تا مرورگرها به ⁦HTTP/2⁩ بروند. فیلتری که QUIC را تمیز مسدود کند بی‌ضرر است؛ فیلتری که نخستین بسته‌ها را عبور می‌دهد و بقیه را دور می‌ریزد، این خطا را ایجاد می‌کند.

مودم‌ها و فایروال‌ها هم هر گفت‌وگویی را که از آن‌ها می‌گذرد دنبال می‌کنند. ⁦RFC 9308⁩، راهنمای IETF برای به‌کارگیری QUIC، یادآوری می‌کند که این دستگاه‌ها یک گفت‌وگوی UDP بی‌فعالیت را بسیار زودتر از یک گفت‌وگوی TCP فراموش می‌کنند و برخی فایروال‌ها پس از آن بسته‌هایی از سرور را که دیگر انتظارشان را ندارند رد می‌کنند. به همین دلیل زبانه‌ای که مدتی بی‌صدا باز مانده ممکن است با کلیک بعدی خطا بدهد.

خطای ERR_QUIC_PROTOCOL_ERROR را چگونه رفع کنیم؟#

این گام‌ها را به ترتیب انجام دهید و پس از هر گام صفحه را دوباره بارگذاری کنید:

1. یک بار دوباره بارگذاری کنید. یک قطعی یک‌باره، مانند یک اختلال کوتاه در وای‌فای، اغلب تکرار نمی‌شود.
2. شبکه دیگری را امتحان کنید. سایت را با اینترنت همراه گوشی یا یک هات‌اسپات باز کنید. اگر آنجا کار کرد، سایت سالم است.
3. VPN را قطع کنید. اگر صفحه پس از آن باز شد، در برنامه VPN سرور دیگری یا پروتکل اتصال دیگری را امتحان کنید.
4. محافظت وب آنتی‌ویروس را برای یک آزمایش متوقف کنید. قابلیتی را که ترافیک وب یا HTTPS را اسکن می‌کند خاموش کنید، صفحه را دوباره بارگذاری کنید و سپس آن را دوباره روشن کنید. اگر توقف کمک کرد، برنامه را به‌روز کنید و در صفحه‌های راهنمای آن ⁦HTTP/3⁩ یا QUIC را جست‌وجو کنید؛ برخی سازندگان به جای آن گام بعدی را توصیه می‌کنند.
5. QUIC را در مرورگر خاموش کنید. این کار در هر حالتی خطا را از بین می‌برد، چون مرورگر دیگر از QUIC استفاده نمی‌کند. گام‌ها در ادامه آمده‌اند.
6. در رایانه محل کار یا مدرسه از واحد فناوری اطلاعات (IT) بپرسید. فایروال و تنظیمات مرورگر متعلق به سازمان است و راه‌حل هم همین‌طور.

QUIC را در کروم و اج چگونه خاموش کنیم؟#

QUIC به‌طور پیش‌فرض روشن است. کلید آن در صفحه آزمایش‌های مرورگر است، جایی که نام پرچم‌ها (flags) در همه زبان‌ها انگلیسی می‌ماند. در کروم روی ویندوز، مک، لینوکس یا اندروید:

1. chrome://flags/#enable-quic را در نوار آدرس بنویسید و کلید Enter را بزنید. صفحه مستقیم به Experimental QUIC protocol می‌رود.
2. منوی کنار آن را از Default به Disabled تغییر دهید.
3. روی راه‌اندازی مجدد (در رابط انگلیسی Relaunch) در پایین صفحه کلیک کنید. کروم بسته می‌شود و دوباره باز می‌شود.

در اج، edge://flags/#enable-quic را بنویسید، Experimental QUIC protocol را روی Disabled بگذارید و روی Restart (راه‌اندازی مجدد) کلیک کنید.

آنچه از دست می‌دهید ⁦HTTP/3⁩ است. صفحه‌ها با ⁦HTTP/2⁩ یا ⁦HTTP/1.1⁩ روی TCP بارگذاری می‌شوند و در یک اتصال خوب به‌ندرت تفاوتی حس می‌کنید. برای برگرداندن تغییر، پرچم را دوباره روی Default بگذارید. این را یک راه موقت بدانید: اگر یک برنامه امنیتی باعث خطا شده است، راه‌حل اصلی به‌روزرسانی یا تغییر تنظیمات همان برنامه است.

سازمان‌ها QUIC را به‌صورت متمرکز با خط‌مشی‌ای به نام QuicAllowed (⁦"Allow QUIC protocol"⁩) خاموش می‌کنند که در کروم و اج نام یکسانی دارد (مستندات مایکروسافت). برای دیدن خط‌مشی‌های رایانه‌تان chrome://policy را در نوار آدرس بنویسید؛ اگر QuicAllowed در فهرست آمده باشد، سازمان شما تصمیم می‌گیرد که QUIC استفاده شود یا نه.

آیا مشکل از وب‌سایت است؟#

گاهی. اگر یک سایت در همه شبکه‌ها و دستگاه‌ها خطا می‌دهد در حالی که سایت‌های دیگر کار می‌کنند، علت احتمالی سرور ⁦HTTP/3⁩ آن یا شبکه توزیع محتوا (CDN، شبکه‌ای از سرورها که صفحه‌های یک سایت را از مکانی نزدیک به شما می‌رساند) است. فقط صاحب سایت می‌تواند آن را درست کند؛ تا آن زمان، خاموش کردن QUIC مشکل را برطرف می‌کند.

اگر سایت مال شماست، نخست با بازدیدکنندگانی در شبکه‌های دیگر مطمئن شوید، سپس ⁦HTTP/3⁩ را برای یک آزمایش خاموش کنید؛ در Cloudflare این کلید در ⁦Speed > Settings > Protocol Optimization > HTTP/3⁩ است. اگر سایت پشت متعادل‌کننده بار خودتان است، ⁦RFC 9308⁩ هشدار می‌دهد که متعادل‌کننده‌هایی که بر اساس آدرس و پورت مسیریابی می‌کنند، وقتی مودم یک بازدیدکننده پورت را تغییر می‌دهد، می‌توانند QUIC را بشکنند.

آیا VPN و پروکسی باعث این خطا می‌شوند؟#

یک برنامه VPN تمام ترافیک دستگاه شما، از جمله UDP، را درون یک تونل رمزگذاری‌شده به سرور خودش می‌برد. پیچیدن هر بسته درون بسته‌ای دیگر جای کمتری برای هر بسته باقی می‌گذارد و ⁦RFC 9000⁩ می‌گوید QUIC نباید روی مسیری به کار رود که نمی‌تواند بسته‌های UDP دست‌کم 1,200 بایتی را حمل کند. سرور VPN که UDP را عبور نمی‌دهد، یا تونلی که جای کافی ندارد، QUIC را می‌شکند؛ سرور یا پروتکل را در برنامه تغییر دهید.

پروکسی‌ای که در مرورگر تنظیم شده باشد طور دیگری کار می‌کند. با یک پروکسی HTTP یا HTTPS، کروم با یک درخواست CONNECT که روی TCP اجرا می‌شود از پروکسی یک تونل به سایت می‌خواهد. توضیحی در کد اتصال کرومیوم می‌گوید QUIC را نمی‌توان با پروکسی‌هایی که پروکسی QUIC نیستند به کار برد، پس کروم سایت را با ⁦HTTP/2⁩ یا ⁦HTTP/1.1⁩ بارگذاری می‌کند و این خطا رخ نمی‌دهد.

SOCKS5 مورد خاصی است، چون خود این پروتکل می‌تواند علاوه بر TCP، ترافیک UDP را هم حمل کند؛ نوشته پروکسی SOCKS5 چیست؟ توضیح می‌دهد چگونه.

کروم از این بخش استفاده نمی‌کند. مستندات پروکسی آن می‌گوید SOCKS5 در کروم فقط درخواست‌های TCP را جابه‌جا می‌کند و ⁦"cannot be used to relay UDP traffic"⁩ (نمی‌توان از آن برای انتقال ترافیک UDP استفاده کرد). پروکسی SOCKS5 ما ترافیک UDP را برای برنامه‌هایی که خودشان آن را می‌فرستند منتقل می‌کند، اما در کروم صفحه‌ها را مانند هر پروکسی دیگری روی TCP حمل می‌کند.

این همچنین چیزی را توضیح می‌دهد که در کار روزمره می‌بینید. وقتی با یک پروکسی مسکونی بررسی می‌کنید که یک فروشگاه از کشوری دیگر چگونه دیده می‌شود، ابزارهای برنامه‌نویس مرورگر (DevTools) جایی که بازدید مستقیم h3 نشان می‌دهد، h2 نشان می‌دهند. این رفتار مورد انتظار است، نه ایراد. پروکسی راه‌حل این خطا هم نیست: خاموش کردن QUIC همان اثر را دارد، بی‌آنکه ترافیک شما از سرور کس دیگری بگذرد.

سطح پیشرفته: بررسی اینکه یک سایت از ⁦HTTP/3⁩ استفاده می‌کند یا نه#

این بخش برای خوانندگانی است که می‌خواهند خودشان آن را ببینند. DevTools پروتکل هر درخواست را نشان می‌دهد:

1. سایت را باز کنید و ⁦F12⁩ یا ⁦Ctrl+Shift+I⁩ (در مک ⁦Cmd+Option+I⁩) را بزنید، سپس پنل شبکه (Network) را انتخاب کنید.
2. روی سرستون‌های جدول درخواست‌ها راست‌کلیک کنید و پروتکل (Protocol) را انتخاب کنید.
3. صفحه را دوباره بارگذاری کنید. h3 یعنی ⁦HTTP/3⁩ روی QUIC و h2 یعنی ⁦HTTP/2⁩ روی TCP.

اگر سایت مشکل‌دار در شبکه‌ای که در آن کار می‌کند h3 نشان دهد، QUIC در کار است و خاموش کردن آن خطا را از بین می‌برد. برای دیدن پیشنهاد ⁦HTTP/3⁩ یک سایت بدون مرورگر، هدرهای آن را با curl درخواست کنید که در ویندوز 10، ویندوز 11 و macOS از پیش نصب است؛ در PowerShell ویندوز به جای آن curl.exe بنویسید.

curl -sI https://example.com

اجرای ما در 6 اکتبر 2026 (⁦curl 8.21.0⁩، ویندوز 11) در میان هدرهای دیگر این سطر را برگرداند:

alt-svc: h3=":443"; ma=86400

نبود h3 در پاسخ معمولاً یعنی سایت ⁦HTTP/3⁩ را از این راه پیشنهاد نمی‌دهد.

خطاهای مرتبط#

اگر خاموش کردن QUIC خطا را به ERR_SSL_PROTOCOL_ERROR تبدیل کرد، همان فیلتر اکنون اتصال TCP را می‌شکند و رفع خطای ⁦err_ssl_protocol_error⁩ در کروم و اج از همان‌جا ادامه می‌دهد.

کجا ممکن است با این خطا روبه‌رو شوید؟#

• یوتیوب و سرویس‌های گوگل که ⁦HTTP/3⁩ را به همه بازدیدکنندگان پیشنهاد می‌دهند و از مرورگرها می‌خواهند آن را 30 روز به خاطر بسپارند.
• سایت‌های پشت Cloudflare که ⁦HTTP/3⁩ را در همه پلن‌های خود ارائه می‌دهد.
• شبکه‌های اداری و مدرسه که فایروال‌هایشان ترافیک وب را بازرسی می‌کنند.
• رایانه‌هایی با یک بسته امنیت اینترنت که صفحه‌های وب را فیلتر می‌کند.

اشتباه‌های رایج#

• پاک کردن کوکی‌ها و حافظه پنهان (کش). این‌ها صفحه‌ها و ورودها را نگه می‌دارند، نه اتصال را؛ قطع شدن در لایه‌ای زیر آن‌ها رخ می‌دهد.
• نصب دوباره کروم. نصب تازه دوباره به‌طور پیش‌فرض از QUIC استفاده می‌کند.
• خاموش گذاشتن همیشگی محافظت وب به جای به‌روزرسانی برنامه یا خاموش کردن QUIC.
• مقصر دانستن سایت پس از یک بار شکست. نخست شبکه دیگری را امتحان کنید.
• تغییر تنظیمات رایانه محل کار بدون پرسیدن. فایروالی که QUIC را می‌شکند متعلق به سازمان است.

راهنمای انتخاب#

پرسش‌های متداول#

آیا خاموش کردن QUIC امن است؟#

بله. صفحه‌ها همچنان رمزگذاری‌شده منتقل می‌شوند، با TLS روی TCP به جای QUIC، همان‌طور که بیشتر وب پیش از ⁦HTTP/3⁩ کار می‌کرد. هر زمان بخواهید می‌توانید پرچم را به Default برگردانید.

آیا خاموش کردن QUIC وب‌گردی را کند می‌کند؟#

در برخی سایت‌ها، کمی. QUIC اتصال‌ها را سریع‌تر برقرار می‌کند و با گم شدن بسته‌ها بهتر کنار می‌آید، پس تفاوت بیشتر در اتصال‌های ضعیف اینترنت همراه یا وای‌فای دیده می‌شود.

چرا این خطا بیشتر در یوتیوب و سایت‌های گوگل رخ می‌دهد؟#

کروم با این سایت‌ها بیشتر از اغلب سایت‌ها از QUIC استفاده می‌کند، چون آن‌ها ⁦HTTP/3⁩ را به همه بازدیدکنندگان پیشنهاد می‌دهند. فیلتری که QUIC را نادرست مدیریت می‌کند، نخست آنجا خودش را نشان می‌دهد.

در اندروید چگونه آن را رفع کنم؟#

نخست میان وای‌فای و اینترنت همراه جابه‌جا شوید و هر برنامه VPN را خاموش کنید. اگر خطا ماند، در کروم اندروید chrome://flags/#enable-quic را باز کنید و Experimental QUIC protocol را روی Disabled بگذارید.

آیا فایرفاکس خطای ERR_QUIC_PROTOCOL_ERROR نشان می‌دهد؟#

نه. این کد متعلق به کرومیوم است، موتوری که پشت کروم، اج، بریو و اپرا قرار دارد. فایرفاکس پشتیبانی خودش از ⁦HTTP/3⁩ و نام‌های خطای خودش را دارد.

آیا پروکسی یا VPN این خطا را رفع می‌کند؟#

VPN بیشتر علت است تا درمان. پروکسی مرورگر فقط به‌عنوان یک اثر جانبی خطا را از بین می‌برد، چون کروم از طریق پروکسی‌های معمولی از QUIC استفاده نمی‌کند؛ خاموش کردن پرچم QUIC هم همین کار را می‌کند.

خلاصه#

ERR_QUIC_PROTOCOL_ERROR یعنی یک اتصال QUIC، یعنی پروتکل انتقال مبتنی بر UDP که ⁦HTTP/3⁩ بر آن تکیه دارد، پس از آنکه سایت شروع به پاسخ دادن کرده بود قطع شده است، پس کروم نتوانسته بی‌صدا به TCP برگردد. برای پیدا کردن عامل مزاحم، شبکه دیگری، VPN و محافظت وب آنتی‌ویروس خود را بیازمایید و اگر همین حالا به صفحه نیاز دارید، Experimental QUIC protocol را روی Disabled بگذارید. اگر برای کار مرورگر را از طریق پروکسی عبور می‌دهید، آنجا انتظار ⁦HTTP/2⁩ را داشته باشید؛ انواع پروکسی و پروتکل‌ها را می‌توانید در صفحه پروکسی ما مقایسه کنید.