خطای 505 HTTP Version Not Supported در سرور زمانی رخ می‌دهد که کلاینت، درخواست خود را با نسخه‌ای از پروتکل HTTP ارسال کند که سرور قادر به پردازش آن نیست. برخلاف بسیاری از خطاهای 5xx که مبهم و گاه ناشی از فروپاشی داخلی سرور هستند، کد 505 یک پیام دقیق و صریح است: «من این نسخه از پروتکل را نمی‌شناسم یا پیاده‌سازی نکرده‌ام». این خطا در ظاهر ساده به نظر می‌رسد اما در عمل، ریشه‌یابی آن نیازمند درک عمیق از تاریخچه نسخه‌های HTTP، مکانیزم ALPN (Application-Layer Protocol Negotiation)، تنظیمات وب‌سرور، پروکسی معکوس و کتابخانه‌های کلاینت است. در این مقاله، همان مسیری را طی می‌کنم که در پروژه‌های واقعی برای ردیابی این خطا استفاده کرده‌ام.

505 HTTP Version Not Supported دقیقاً چه معنایی دارد؟

در استاندارد HTTP Status Codes، کد 505 در دسته 5xx (خطای سرور) قرار می‌گیرد و طبق RFC 7231 و به‌روزرسانی‌های بعدی به این معناست: «سرور از نسخه اصلی پروتکل HTTP که در درخواست استفاده شده، پشتیبانی نمی‌کند». این پیام چند نکته کلیدی دارد. اول، سرور سالم است و درخواست را دریافت کرده؛ مشکل در لایه «نسخه پروتکل» است. دوم، این خطا معمولاً ناشی از پیکربندی سرور، پروکسی معکوس یا CDN است، نه اپلیکیشن. سوم، کلاینت همیشه مقصر نیست؛ ممکن است درخواست کاملاً استاندارد باشد اما سرور یا لایه میانی، نسخه‌ای که کلاینت استفاده کرده را نشناسد.

برای درک دقیق‌تر، باید بدانید که HTTP یک پروتکل با نسخه‌های متعدد است: HTTP/0.9، HTTP/1.0، HTTP/1.1، HTTP/2 و HTTP/3. هر نسخه، ساختار پیام و مکانیزم انتقال متفاوتی دارد. سرورها معمولاً از چند نسخه پشتیبانی می‌کنند و از طریق هدر یا مکانیزم ALPN انتخاب می‌کنند. اگر کلاینتی نسخه‌ای را استفاده کند که سرور در پیکربندی خود نشناخته باشد، پاسخ 505 صادر می‌شود. اگر با معماری کلی سرور و پروتکل HTTP آشنایی ندارید، ابتدا سرور چیست و چگونه کار می‌کند را بخوانید تا چارچوب ذهنی‌تان شکل بگیرد.

505 به کلاینت می‌گوید «این نسخه پروتکل برای من ناشناخته است». راه‌حل، هماهنگ‌کردن نسخه‌های HTTP در همه لایه‌های مسیر است، نه تغییر اپلیکیشن.

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

در تجربه من، خطای 505 همیشه در یکی از این سه لایه ریشه دارد. تفکیک لایه پیش از هر اقدام، نیمی از راه را رفته‌اید:

  • لایه وب‌سرور: Nginx، Apache یا IIS در پیکربندی خود، نسخه‌ای از HTTP را محدود کرده یا ماژول مربوطه را فعال نکرده است.
  • لایه میان‌راهی: پروکسی معکوس، CDN، WAF یا لودبالانسر، نسخه پروتکل را قبل از رسیدن به سرور اصلی تغییر می‌دهد یا محدود می‌کند.
  • لایه کلاینت: کتابخانه HTTP، SDK یا ابزار تست، نسخه‌ای از پروتکل را ارسال می‌کند که سرور پشتیبانی نمی‌کند.

جدول زیر نگاشت سریع سیمپتوم به لایه خطا را نشان می‌دهد:

سیمپتوملایه احتمالیاولین اقدام تشخیصی
505 فقط از یک کتابخانه خاصلایه کلاینتبررسی نسخه HTTP در کتابخانه
505 روی همه درخواست‌ها حتی از مرورگرلایه وب‌سروربررسی ماژول‌های HTTP/2 و HTTP/3
505 بعد از افزودن CDNلایه میان‌راهیبررسی ALPN و TLS در CDN
505 فقط برای بعضی endpointهالایه اپلیکیشن یا پروکسیبررسی routing و TLS termination

تفاوت 505 با 400، 501، 502 و 503

یکی از پرتکرارترین اشتباهات در عیب‌یابی، قاطی کردن کدهای 5xx با همدیگر است. تفاوت بین 505 با کدهای همسایه‌اش را در یک نگاه:

کدمعنامسئول خطا
400 Bad Requestساختار درخواست نامعتبر استکلاینت
501 Not Implementedمتد HTTP پشتیبانی نمی‌شودسرور
502 Bad Gatewayپاسخ نامعتبر از سرور بالادستیسرور بالادستی
503 Service Unavailableسرور در دسترس نیست یا اضافه‌بارسرور
505 HTTP Version Not Supportedنسخه HTTP پشتیبانی نمی‌شودسرور یا لایه میانی

این تفکیک در عیب‌یابی حیاتی است. اگر سرور 501 برگرداند، متد یا قابلیت در سطح سرور پشتیبانی نمی‌شود. اگر 505 برگرداند، نسخه پروتکل HTTP مسئله است — که در لایه‌ای کاملاً متفاوت (پروتکل انتقال) ریشه دارد. برای درک جایگاه این خطاها در معماری کلی وب، معماری وب چیست و اصول آن در اصول طراحی معماری وب مدرن راهنمای دقیقی هستند. تفاوت دقیق 401 و 403 و سایر کدهای هم‌خانواده هم در مقالات جداگانه بررسی شده است.

505 با 400 تفاوت بنیادین دارد: 400 می‌گوید «ساختار درخواست را نمی‌فهمم»، اما 505 می‌گوید «ساختار را می‌فهمم، اما این نسخه از پروتکل را نمی‌شناسم». یکی به محتوا اشاره دارد، دیگری به پروتکل.

تاریخچه و تفاوت نسخه‌های HTTP

برای فهم عمیق خطای 505، باید بدانید HTTP در طول سه دهه، پنج نسخه اصلی را تجربه کرده است. هر نسخه، ویژگی‌ها و محدودیت‌های خاص خودش را دارد و پشتیبانی از آن‌ها در سرورها متفاوت است.

HTTP/0.9 و HTTP/1.0

HTTP/0.9 ساده‌ترین نسخه بود و فقط از متد GET پشتیبانی می‌کرد. HTTP/1.0 در سال ۱۹۹۶ به‌عنوان اولین نسخه استاندارد معرفی شد و مفاهیمی مثل هدرها و کدهای وضعیت را اضافه کرد. این دو نسخه امروزه در عمل منسوخ شده‌اند و اکثر سرورهای مدرن از پذیرش آن‌ها خودداری می‌کنند. اگر کلاینتی با این نسخه‌ها درخواست بفرستد، سرور ممکن است پاسخ 505 بدهد.

HTTP/1.1 و چالش‌های پهنای باند

HTTP/1.1 در سال ۱۹۹۷ معرفی شد و مکانیزم‌هایی مثل keep-alive، pipelining و chunked transfer encoding را اضافه کرد. این نسخه تا امروز در بسیاری از سرورها فعال است اما به‌دلیل محدودیت‌های پهنای باند و head-of-line blocking، در سال‌های اخیر با HTTP/2 و HTTP/3 جایگزین شده است.

HTTP/2 و انقلاب multiplexing

HTTP/2 در سال ۲۰۱۵ به‌عنوان RFC 7540 منتشر شد و مفاهیمی مثل multiplexing، server push و header compression را معرفی کرد. HTTP/2 روی TLS اجرا می‌شود و انتخاب آن از طریق ALPN انجام می‌گیرد. اگر سروری HTTP/2 را پشتیبانی نکند، کلاینت به HTTP/1.1 برمی‌گردد. اما اگر سروری HTTP/2 را به‌عنوان اجباری تنظیم کند و کلاینت ارسال HTTP/1.1 کند، ممکن است پاسخ 505 بدهد.

HTTP/3 و QUIC روی UDP

HTTP/3 آخرین نسخه استاندارد HTTP است که در سال ۲۰۲۲ به‌عنوان RFC 9114 منتشر شد و بر پایه پروتکل QUIC (که روی UDP اجرا می‌شود) ساخته شده است. HTTP/3 در سال‌های اخیر در CDNهای بزرگ مثل Cloudflare و Google فعال شده اما در سرورهای سنتی و هاست‌های اشتراکی کمتر دیده می‌شود. اگر CDN شما HTTP/3 را برای کلاینت فعال کند اما سرور بالادستی از آن پشتیبانی نکند، ممکن است 505 رخ دهد.

درک تفاوت این نسخه‌ها برای عیب‌یابی 505 حیاتی است. اگر نمی‌دانید سرور شما در حال حاضر از کدام نسخه پشتیبانی می‌کند، می‌توانید از ابزارهای آنلاین یا دستورات CLI مثل curl --http2 -I https://example.com استفاده کنید. روش دقیق دستورات سرور را در دستورات ضروری CLI برای مدیریت سرور آورده‌ام.

505 در بستر انتقال HTTP شکل می‌گیرد، نه در اپلیکیشن. برای رفع آن، ابتدا باید بدانید در مسیر درخواست، کدام نسخه از HTTP در حال استفاده است و کدام لایه، نسخه را محدود می‌کند.

ALPN و نقش آن در انتخاب نسخه HTTP

ALPN (Application-Layer Protocol Negotiation) مکانیزمی است که در لایه TLS قرار می‌گیرد و به کلاینت و سرور اجازه می‌دهد پیش از شروع ارتباط HTTP، بر سر نسخه پروتکل توافق کنند. این مکانیزم در RFC 7301 تعریف شده و از TLS 1.2 به بعد به‌طور پیش‌فرض پشتیبانی می‌شود. برای HTTP/2 و HTTP/3، ALPN الزامی است — یعنی بدون ALPN، این نسخه‌ها به‌طور کامل کار نمی‌کنند.

سه سناریوی دقیق که در آن‌ها ALPN باعث 505 می‌شود:

  1. پروکسی معکوس با ALPN ناقص: اگر پروکسی معکوس شما، ALPN را به‌درستی به سرور بالادستی منتقل نکند، ممکن است سرور نسخه پیش‌فرض HTTP/1.0 را انتخاب کند و پاسخ 505 بدهد. این سناریو در معماری‌های چندلایه شایع است.
  2. عدم تطابق ALPN بین CDN و سرور: اگر CDN شما ALPN را برای HTTP/2 یا HTTP/3 تبلیغ کند اما سرور اصلی از آن پشتیبانی نکند، ممکن است درخواست با 505 رد شود. راه‌حل: هماهنگ‌سازی تنظیمات ALPN در همه لایه‌ها.
  3. کلاینت‌های قدیمی بدون ALPN: بعضی کتابخانه‌های HTTP قدیمی، ALPN را در handshake TLS ارسال نمی‌کنند. در این حالت، سرور ممکن است نسخه پیش‌فرض را انتخاب کند یا با 505 پاسخ دهد.

روش تشخیص قطعی: با curl -v --http2 https://example.com درخواست بزنید و بخش TLS handshake را در خروجی ببینید. اگر ALPN با مقدار h2 یا http/1.1 رد و بدل شده باشد، ریشه در لایه دیگری است. اگر ALPN غایب باشد، ریشه در لایه پروتکل است.

505 در Nginx و پیکربندی آن

Nginx به‌طور پیش‌فرض از HTTP/1.0، HTTP/1.1 و HTTP/2 پشتیبانی می‌کند. اما در پیکربندی‌های سفارشی، ممکن است بعضی نسخه‌ها غیرفعال شوند یا ماژول مربوطه فعال نباشد. در این حالت، درخواست‌های مربوطه با 505 پاسخ داده می‌شوند. سه سناریوی دقیق در این لایه:

  1. نبود ماژول ngx_http_v2_module: اگر Nginx با فلگ --with-http_v2_module کامپایل نشده باشد، امکان پشتیبانی از HTTP/2 وجود ندارد. اگر درخواستی با HTTP/2 بیاید و این ماژول فعال نباشد، Nginx ممکن است 505 برگرداند یا به HTTP/1.1 تنزل دهد.
  2. خطای ناهماهنگی listen directive: در پیکربندی Nginx، خط listen 443 ssl http2; برای فعال‌سازی HTTP/2 استفاده می‌شود. اگر این خط اشتباه باشد (مثلاً فقط listen 443 ssl;)، HTTP/2 غیرفعال می‌شود و درخواست HTTP/2 ممکن است 505 بگیرد.
  3. پروکسی معکوس با version mismatch: اگر Nginx به‌عنوان پروکسی معکوس عمل کند و در پیکربندی proxy_http_version اشتباه تنظیم شده باشد، ممکن است نسخه HTTP نامناسبی به سرور بالادستی ارسال شود و پاسخ 505 بگیرد. مقدار درست معمولاً proxy_http_version 1.1; است.

روش تشخیص: با nginx -V 2>&1 | tr " " "\n" | grep with-http بررسی کنید که ماژول‌های مورد نیاز نصب هستند یا نه. سپس فایل پیکربندی را برای کلمات http2، http3، proxy_http_version و listen 443 جست‌وجو کنید. برای عیب‌یابی عمیق‌تر لاگ‌ها، بررسی خطاهای سرور در لاگ‌ها راهنمای دقیقی است.

505 در Apache و ماژول‌ها

Apache از طریق ماژول mod_http2 از HTTP/2 پشتیبانی می‌کند. در نسخه‌های Apache 2.4 به بعد، این ماژول به‌طور پیش‌فرض در دسترس است اما ممکن است در بعضی بیلدها فعال نباشد. سه سناریوی دقیق در این لایه:

  1. نبود mod_http2: اگر Apache با این ماژول کامپایل نشده باشد، درخواست‌های HTTP/2 با 505 یا خطای دیگری پاسخ می‌گیرند. راه‌حل: نصب مجدد Apache با --enable-http2.
  2. پیکربندی اشتباه Protocols directive: در Apache 2.4، خط Protocols h2 http/1.1 برای فعال‌سازی HTTP/2 استفاده می‌شود. اگر این خط اشتباه باشد (مثلاً فقط Protocols http/1.1)، HTTP/2 غیرفعال می‌شود.
  3. تضاد با mod_php یا mod_cgi: بعضی ماژول‌های قدیمی Apache، با HTTP/2 ناسازگار هستند. در این حالت، ممکن است Apache 505 برگرداند یا خطای دیگری بدهد. راه‌حل: استفاده از PHP-FPM به‌جای mod_php.

روش تشخیص: با apachectl -M | grep http2 بررسی کنید که ماژول نصب است یا نه. سپس فایل پیکربندی را برای کلمه Protocols جست‌وجو کنید. مبانی امنیت سرور Apache را در امنیت سرور چه اصولی دارد و روش افزایش امنیت سرور را در افزایش امنیت سرور آورده‌ام.

505 در IIS و Windows Server

در Microsoft IIS، پشتیبانی از HTTP/2 از نسخه IIS 10 (که با Windows Server 2016 منتشر شد) ارائه شده است. در نسخه‌های قدیمی‌تر، HTTP/2 پشتیبانی نمی‌شود و درخواست‌های مربوطه ممکن است 505 بگیرند. سه سناریوی دقیق در IIS:

  • IIS قدیمی‌تر از نسخه 10: IIS 8.5 (Windows Server 2012 R2) و قدیمی‌تر، HTTP/2 را پشتیبانی نمی‌کنند. اگر کلاینتی درخواست HTTP/2 بفرستد، IIS ممکن است با 505 پاسخ دهد. راه‌حل: ارتقا به Windows Server 2016 یا بالاتر.
  • نبود پیکربندی TLS برای HTTP/2: IIS از HTTP/2 فقط روی TLS 1.2 به بالا پشتیبانی می‌کند. اگر TLS 1.0 یا 1.1 تنظیم شده باشد، HTTP/2 غیرفعال می‌شود.
  • Request Filtering با محدودیت نسخه: در بعضی پیکربندی‌ها، IIS Request Filtering می‌تواند نسخه HTTP را محدود کند. راه‌حل: بررسی تنظیمات Request Filtering و رفع محدودیت.

روش تشخیص: در IIS Manager، بخش «HTTP Response Headers» یا «SSL Settings» را بررسی کنید. مطمئن شوید TLS 1.2 یا 1.3 فعال است و IIS 10 یا بالاتر در حال اجراست. مبانی سرور Windows و لینوکس را در تفاوت سرور لینوکس و ویندوز آورده‌ام.

در IIS، دامنه پشتیبانی از HTTP/2 به نسخه ویندوز و تنظیمات TLS وابسته است. اگر روی نسخه‌های قدیمی میزبانی می‌کنید، خطای 505 ممکن است شایع باشد.

505 در پروکسی معکوس و لودبالانسر

در معماری‌های مدرن، درخواست‌ها اغلب از یک پروکسی معکوس (Nginx، HAProxy، Traefik) یا لودبالانسر (AWS ALB، Cloudflare Load Balancer) عبور می‌کنند. اگر این لایه‌ها، نسخه HTTP را به‌درستی مدیریت نکنند، ممکن است 505 برگردانند. سه سناریوی دقیق:

  1. HAProxy با پشتیبانی ناقص HTTP/2: HAProxy تا نسخه 2.4 فقط به‌صورت آزمایشی از HTTP/2 پشتیبانی می‌کرد. اگر نسخه‌ای قدیمی‌تر استفاده شود، ممکن است درخواست‌های HTTP/2 با 505 پاسخ بگیرند.
  2. Traefik با پیکربندی اشتباه: Traefik از HTTP/2 و HTTP/3 پشتیبانی می‌کند اما پیکربندی آن حساس است. اگر entrypoint به‌درستی تعریف نشده باشد، ممکن است نسخه پروتکل درست منتقل نشود.
  3. لودبالانسر با downgrade اجباری: بعضی لودبالانسرها به‌دلیل مسائل امنیتی یا سازگاری، درخواست‌های HTTP/2 را به HTTP/1.1 تنزل می‌دهند. اگر سرور بالادستی انتظار HTTP/2 داشته باشد، ممکن است 505 بگیرد.

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

505 در CDN، WAF و API Gateway

CDNها و WAFها معمولاً به‌عنوان لایه اول مواجهه با درخواست‌های کاربر عمل می‌کنند و نقش مهمی در مدیریت نسخه‌های HTTP دارند. اگر این لایه‌ها، نسخه‌ای را که کاربر ارسال کرده، نشناسند یا پشتیبانی نکنند، ممکن است 505 برگردانند. سه سناریوی دقیق:

  1. CDN با پشتیبانی محدود HTTP/3: بعضی CDNها HTTP/3 را فقط در پلن‌های بالاتر فعال می‌کنند. اگر کلاینتی درخواست HTTP/3 بفرستد و CDN پشتیبانی نکند، ممکن است 505 یا خطای دیگری بگیرد.
  2. WAF با سیاست سخت‌گیرانه: بعضی WAFها، نسخه‌های قدیمی HTTP (مثل HTTP/1.0) را به‌عنوان «ناامن» علامت می‌زنند و 505 برمی‌گردانند. اگر کلاینت شما از کتابخانه قدیمی استفاده کند، این سناریو رخ می‌دهد.
  3. API Gateway با پشتیبانی ناقص: بعضی API Gatewayها فقط HTTP/1.1 را پشتیبانی می‌کنند. اگر اپلیکیشن شما با HTTP/2 به API Gateway وصل شود، پاسخ 505 می‌گیرد.

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

505 در وردپرس و REST API

در وردپرس، خطای 505 به‌طور مستقیم از هسته صادر نمی‌شود؛ چون وردپرس در لایه اپلیکیشن قرار دارد و پردازش نسخه HTTP در لایه وب‌سرور انجام می‌شود. اما در پیکربندی‌های خاص، ممکن است 505 از سه مسیر رخ دهد:

  1. CDN با محدودیت روی wp-json: اگر CDN شما فقط HTTP/1.1 را به /wp-json/ اجازه دهد اما کلاینت HTTP/2 بفرستد، ممکن است 505 بگیرید. راه‌حل: هماهنگ‌سازی تنظیمات نسخه HTTP در CDN.
  2. افزونه‌های امنیتی با محدودیت پروتکل: بعضی افزونه‌های امنیتی، درخواست‌های HTTP/1.0 را بلاک می‌کنند. اگر کلاینت با این نسخه درخواست بفرستد، پاسخ 505 یا 403 می‌گیرد.
  3. هاستینگ اشتراکی با پشتیبانی محدود: بعضی هاست‌های اشتراکی، HTTP/2 را در تنظیمات خود فعال نمی‌کنند. اگر وردپرس شما با این هاست کار کند و CDN بالادستی HTTP/2 تبلیغ کند، ممکن است در لایه واسط 505 رخ دهد.

راهنمای کامل REST API وردپرس در API در وردپرس و روش استفاده در استفاده از REST API در وردپرس آمده است. برای اطمینان از پیکربندی درست سرور وردپرس، سرور وردپرس چه مشخصاتی باید داشته باشد راهنمای دقیقی است. اگر خطا در لایه SSL باشد، خطای SSL سرور و خطای DNS سرور مسیرهای مکمل عیب‌یابی هستند.

505 در کتابخانه‌های کلاینت و SDK

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

  1. Python requests با HTTP/1.1: کتابخانه requests به‌طور پیش‌فرض HTTP/1.1 ارسال می‌کند. اگر سرور شما HTTP/2 را اجباری کرده باشد، ممکن است 505 بگیرید. راه‌حل: استفاده از کتابخانه httpx یا aiohttp که HTTP/2 را پشتیبانی می‌کنند.
  2. cURL قدیمی: نسخه‌های قدیمی cURL، HTTP/2 را پشتیبانی نمی‌کنند. اگر سرور شما HTTP/2 را اجباری کند، cURL قدیمی پاسخ 505 می‌گیرد. راه‌حل: ارتقا cURL به نسخه 7.47 یا بالاتر.
  3. Java HttpClient پیش‌فرض: قبل از Java 11، کلاینت HTTP پیش‌فرض Java، HTTP/2 را پشتیبانی نمی‌کرد. اگر کد شما روی نسخه‌های قدیمی Java اجرا شود، ممکن است در تعامل با سرورهای مدرن 505 بگیرد.

روش تشخیص: لاگ درخواست‌های خروجی از سمت کلاینت را بررسی کنید و نسخه HTTP هر درخواست را ببینید. اگر نسخه‌ای متفاوت از آنچه سرور انتظار دارد ارسال شود، ریشه در لایه کلاینت است. راهنمای اتصال به APIهای خارجی در اتصال ووکامرس به APIهای خارجی آمده است.

دلایل شایع بروز 505

بعد از آشنایی با لایه‌ها، فهرست سریع دلایل شایع 505 در پروژه‌های واقعی را مرور کنیم:

  1. نسخه HTTP ناشناخته در سرور: کلاینت با HTTP/3 یا نسخه‌ای سفارشی درخواست بفرستد که سرور نمی‌شناسد.
  2. نبود ماژول HTTP/2 در Nginx یا Apache: سرور با فلگ‌های محدود کامپایل شده و ماژول مورد نیاز نصب نیست.
  3. محدودیت IIS در نسخه‌های قدیمی: IIS 8.5 و قدیمی‌تر HTTP/2 را پشتیبانی نمی‌کنند.
  4. تنظیمات نادرست ALPN در CDN یا پروکسی معکوس: مکانیزم انتخاب نسخه در لایه TLS نادرست تنظیم شده.
  5. WAF با سیاست تهاجمی: بعضی WAFها نسخه‌های قدیمی HTTP را به‌عنوان «ناامن» بلاک می‌کنند.
  6. API Gateway با پشتیبانی محدود: بعضی Gatewayها فقط HTTP/1.1 را می‌پذیرند.
  7. کتابخانه کلاینت قدیمی: نسخه HTTP قدیمی یا نسخه‌ای که سرور پشتیبانی نمی‌کند ارسال می‌شود.
  8. عدم تطابق در پیکربندی چندلایه: CDN، لودبالانسر و سرور اصلی، نسخه‌های متفاوتی را پشتیبانی می‌کنند.
  9. Downgrade اجباری در پروکسی: بعضی پروکسی‌ها درخواست‌های HTTP/2 را به HTTP/1.1 تنزل می‌دهند و سرور انتظار HTTP/2 دارد.
  10. کلاینت‌های non-browser با پروتکل سفارشی: بعضی ابزارها یا اسکریپت‌ها، نسخه HTTP را دستی تنظیم می‌کنند و ممکن است نسخه‌ای ناسازگار ارسال شود.

پروتکل عیب‌یابی گام‌به‌گام

حالا ترتیب عملی عیب‌یابی، از سریع‌ترین به دقیق‌ترین:

  1. بازتولید و ثبت دقیق: با curl -v --http2 https://example.com درخواست را بزنید و همه هدرهای ارسال و دریافت و بخش TLS handshake را ثبت کنید.
  2. بررسی هدر Server: در پاسخ، هدر Server نشان می‌دهد سرور شما Nginx، Apache، IIS یا چیز دیگری است.
  3. بررسی ALPN در handshake: در خروجی curl -v، بخش ALPN را ببینید. اگر h2 یا http/1.1 رد و بدل شده باشد، ریشه در ALPN نیست.
  4. بررسی لاگ وب‌سرور: در /var/log/nginx/error.log یا /var/log/apache2/error.log، آخرین درخواست‌های مرتبط را ببینید.
  5. بررسی ماژول‌های سرور: با nginx -V یا apachectl -M، مطمئن شوید ماژول‌های HTTP/2 و HTTP/3 نصب هستند.
  6. تست با نسخه‌های مختلف HTTP: با curl --http1.1 https://example.com و curl --http2 تست کنید. اگر یکی از آن‌ها کار کرد و دیگری 505 داد، ریشه در پشتیبانی نسخه است.
  7. بررسی CDN و WAF: لاگ آن‌ها را بررسی کنید که آیا درخواست به سرور اصلی رسیده یا بلاک شده.
  8. بررسی کد کلاینت: اگر از SDK یا کتابخانه استفاده می‌کنید، نسخه HTTP پیش‌فرض آن را بررسی کنید.
  9. بررسی پیکربندی TLS: اطمینان حاصل کنید که TLS 1.2 یا 1.3 فعال است. برای درک تأثیر TLS بر اتصال، خطای SSL سرور راهنمای دقیقی است.
  10. بررسی هدرهای امنیتی: بعضی هدرهای امنیتی مثل Strict-Transport-Security ممکن است بر رفتار نسخه‌ها اثر بگذارند. جزئیات در هدرهای امنیتی HTTP آمده است.

برای خطاهای مرتبط با سرور، خطای 500 Internal Server Error، خطای 502 Bad Gateway و خطای 503 Service Unavailable مسیرهای مکمل عیب‌یابی هستند.

در عیب‌یابی 505، اولین کار این نیست که پیکربندی سرور را دست بزنم. اولین کار این است که بفهمم کلاینت با کدام نسخه HTTP درخواست فرستاده و سرور با کدام نسخه پاسخ داده. تفاوت بین این دو، ریشه خطا را نشان می‌دهد.

اشتباهات پرهزینه در تشخیص

در پرونده‌های پشتیبانی که بازبینی کرده‌ام، این پنج اشتباه بیشتر از بقیه تکرار می‌شود:

  • اشتباه گرفتن 505 با 501: 501 به‌معنای «متد ناشناخته» و 505 به‌معنای «نسخه پروتکل ناشناخته» است. اگر این دو را قاطی کنید، در لایه اشتباه وقت تلف می‌کنید.
  • غیرفعال کردن HTTP/2 برای «رفع سریع»: اگر HTTP/2 را غیرفعال کنید، عملکرد سایت پایین می‌آید. راه‌حل درست: تطبیق نسخه‌ها در همه لایه‌ها.
  • نادیده گرفتن ALPN: نبود ALPN در handshake TLS، ریشه 505 در بسیاری از پرونده‌هاست. این لایه اغلب از چشم توسعه‌دهنده پنهان می‌ماند.
  • تغییر همزمان CDN و سرور: اگر همزمان CDN و سرور را تغییر دهید، نمی‌دانید کدام مؤثر بوده. یک تغییر، یک تست.
  • بی‌توجهی به لایه کلاینت: اگر فقط سرور را بررسی کنید و کتابخانه کلاینت را ندیده بگیرید، ممکن است ریشه را پیدا نکنید. لاگ درخواست‌های خروجی ضروری است.

پرسش و پاسخ کاربردی درباره 505 HTTP Version Not Supported

505 HTTP Version Not Supported با 501 Not Implemented چه تفاوتی دارد؟ 501 به‌معنای «متد HTTP پشتیبانی نمی‌شود» است، در حالی که 505 به‌معنای «نسخه پروتکل HTTP پشتیبانی نمی‌شود». یکی به متد (GET, POST, PUT) اشاره دارد، دیگری به نسخه پروتکل (HTTP/1.1, HTTP/2, HTTP/3).

چرا خطای 505 روی درخواست‌های عادی مرورگر رخ می‌دهد؟ اگر سرور شما HTTP/2 را اجباری کرده باشد اما مرورگر یا پروکسی میانی، HTTP/1.1 ارسال کند، ممکن است 505 بگیرید. راه‌حل: بررسی پیکربندی ALPN و تنظیمات نسخه HTTP در سرور.

آیا 505 می‌تواند از سمت CDN رخ دهد؟ بله. بعضی CDNها HTTP/3 را تبلیغ می‌کنند اما سرور اصلی از آن پشتیبانی نمی‌کند. در این حالت، CDN ممکن است درخواست را با 505 رد کند. راه‌حل: هماهنگ‌سازی نسخه‌های HTTP در همه لایه‌ها.

چرا بعد از نصب IIS جدید، خطای 505 افزایش یافت؟ IIS 10 از HTTP/2 پشتیبانی می‌کند اما IIS 8.5 و قدیمی‌تر نه. اگر کلاینت‌ها HTTP/2 بفرستند و سرور قدیمی باشد، پاسخ 505 رخ می‌دهد. راه‌حل: ارتقا به IIS 10 یا بالاتر یا غیرفعال کردن HTTP/2 در کلاینت‌ها.

آیا Basic Auth یا JWT می‌تواند باعث 505 شود؟ به‌طور مستقیم نه. 505 درباره نسخه پروتکل است، در حالی که Basic Auth و JWT درباره احراز هویت‌اند. اگر خطا در لایه احراز هویت باشد، کد 401 یا 403 برمی‌گردد.

چرا خطای 505 فقط برای بعضی کاربران رخ می‌دهد؟ این نشانه تفاوت در لایه کلاینت یا شبکه است. بعضی کاربران از کتابخانه‌ها یا CDNهایی استفاده می‌کنند که نسخه‌های متفاوتی از HTTP ارسال می‌کنند. لاگ دقیق درخواست‌ها به تفکیک IP و User-Agent، الگو را نشان می‌دهد.

چطور بفهمم سرور از کدام نسخه HTTP پشتیبانی می‌کند؟ با curl -v --http2 https://example.com درخواست بزنید و بخش ALPN در handshake را ببینید. اگر h2 در ALPN باشد، HTTP/2 پشتیبانی می‌شود. اگر http/1.1 باشد، HTTP/2 غیرفعال است.

آیا 505 می‌تواند از سمت دیتابیس رخ دهد؟ خیر، 505 یک کد HTTP است که فقط در لایه پروتکل انتقال معنا دارد. اگر دیتابیس مشکل داشته باشد، معمولاً خطای 500 می‌بینید.

چرا 505 در Nginx شایع‌تر از Apache است؟ Nginx به‌طور پیش‌فرض از HTTP/2 پشتیبانی می‌کند اما فقط اگر با ماژول ngx_http_v2_module کامپایل شده باشد. بعضی بیلدهای Nginx این ماژول را ندارند و در مواجهه با HTTP/2، 505 برمی‌گردانند.

آیا 505 با خطای handshake TLS مرتبط است؟ به‌طور غیر مستقیم بله. اگر handshake TLS با شکست مواجه شود یا ALPN به‌درستی رد و بدل نشود، ممکن است در لایه بالاتر 505 رخ دهد. برای رفع خطاهای مرتبط با TLS، خطای SSL سرور راهنمای دقیقی است.

چطور از بروز 505 در آینده پیشگیری کنم؟ سه اصل: (۱) نسخه‌های HTTP پشتیبانی‌شده در همه لایه‌ها (CDN، پروکسی، سرور) را هماهنگ کنید؛ (۲) ماژول‌های HTTP/2 و HTTP/3 را در Nginx و Apache نصب و فعال کنید؛ (۳) لاگ دقیق درخواست‌های ردشده در وب‌سرور داشته باشید تا ترند را ببینید.

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

آیا کاهش نسخه HTTP می‌تواند 505 را رفع کند؟ بله، اگر ریشه در عدم تطابق نسخه باشد. با تنظیم صریح نسخه HTTP در کلاینت (مثلاً curl --http1.1) می‌توانید تست کنید. اما راه‌حل بلندمدت، هماهنگ‌سازی نسخه‌ها در همه لایه‌ها است، نه کاهش دائم به نسخه قدیمی.

نگاه عملیاتی به خطای 505 و مسیر پایدارسازی

خطای 505 HTTP Version Not Supported در ظاهر یک کد 5xx ساده است؛ در عمل، یک پیام دقیق از سرور درباره «نسخه پروتکل» که در یکی از چند لایه ممکن است شکل گرفته باشد. سه اصل که از این مسیر با من می‌ماند و در هر پروژه واقعی اجرا می‌کنم:

  1. اول لایه را تشخیص بده، بعد راه‌حل را انتخاب کن: 505 می‌تواند از وب‌سرور، پروکسی، CDN، API Gateway یا کتابخانه کلاینت بیاید. با curl -v --http2 و بررسی ALPN و هدرها، اولین قدم را دقیق بردارید.
  2. هماهنگی نسخه HTTP در همه لایه‌ها: در معماری چندلایه، نسخه‌های HTTP باید در همه لایه‌ها هماهنگ باشند. اگر CDN HTTP/3 را تبلیغ می‌کند اما سرور HTTP/1.1 را می‌فهمد، درخواست‌ها در مرز بین لایه‌ها ممکن است با 505 رد شوند. یک مجموعه واحد از نسخه‌های مجاز انتخاب کنید و آن را مستند کنید.
  3. پایش دقیق ترند 505 در لاگ‌ها: یک لاگ یا گزارش داشته باشید که نرخ خطای 505 را در بازه‌های زمانی نشان دهد. اگر ترند صعودی داشت، سریع ریشه را پیدا کنید — قبل از بحران. اصول ثبت لاگ سرور را در بررسی خطاهای سرور در لاگ‌ها آورده‌ام.

اگر در پروژه‌ای با مشکل 505 دست‌وپنجه نرم کرده‌اید، برای من جالب است بدانم کدام لایه بیشترین وقت شما را گرفت: پیکربندی Nginx یا Apache، IIS، CDN، پروکسی معکوس یا کتابخانه کلاینت. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر نشانه‌ای کشف کرده‌اید که در این فهرست نبوده. همین نشانه‌ها، دقیق‌ترین راهنمای نفر بعدی‌اند. 🛰️