خطای 405 Method Not Allowed یکی از آن کدهای وضعیت HTTP است که وقتی رخ می‌دهد، معمولاً بی‌توضیح ظاهر می‌شود و توسعه‌دهنده را سردرگم می‌کند: درخواست شما در مرورگر یا ابزار API بی‌عیب به‌نظر می‌رسد، اما سرور با یک پیام ساده اعلام می‌کند «این متد برای این منبع مجاز نیست». برخلاف تصور عمومی، 405 به‌معنای «آدرس اشتباه» یا «احراز هویت ناقص» نیست؛ این کد یک پیام دقیق از سرور به کلاینت است: «من این منبع را می‌شناسم، اما متد HTTP که فرستاده‌ای روی این منبع پشتیبانی نمی‌شود». تفاوت دقیق این پیام با 404 و 401، الزام هدر Allow در پاسخ، و روش عیب‌یابی آن در لایه‌های مختلف، موضوع اصلی این مقاله است.

405 Method Not Allowed دقیقاً چه معنایی دارد؟

در استاندارد HTTP Status Codes، کد 405 در دسته 4xx (خطای کلاینت) قرار می‌گیرد و به‌طور رسمی به این معناست: «متد HTTP که در درخواست ارسال شده، روی منبع (Resource) هدف پشتیبانی نمی‌شود». این پیام سه پیام ضمنی مهم دارد: اول، سرور منبع درخواستی را می‌شناسد و آن را رد نمی‌کند (این تفاوت کلیدی با 404 است). دوم، سرور می‌داند چه متدهایی روی این منبع معتبرند، و بر اساس RFC باید فهرست آن‌ها را در هدر Allow برگرداند. سوم، مشکل در لایه «متد» است، نه در «آدرس»، «احراز هویت» یا «مجوز».

در عمل، سه نکته دقیق درباره کد 405 وجود دارد که اکثر توسعه‌دهنده‌ها به آن‌ها توجه نمی‌کنند. اول، این کد باید همراه هدر Allow ارسال شود؛ اگر سروری 405 برگرداند اما هدر Allow نداشته باشد، این یک پاسخ ناقص است و طبق استاندارد، رفتار صحیح نیست. دوم، 405 در هر لایه‌ای می‌تواند رخ دهد — از وب‌سرور (Nginx/Apache)، از PHP، از API، از CDN یا از WAF — و تشخیص لایه رخداد، کلید رفع سریع است. سوم، در معماری مدرن، 405 اغلب نتیجه یک تنظیم اشتباه است، نه یک خطای ذاتی: مثلاً فایروال که متد POST را روی یک مسیر بلاک می‌کند. اگر با معماری کلی سرور آشنایی ندارید، ابتدا سرور چیست و چگونه کار می‌کند را بخوانید تا تصویر کلی در ذهن شما شکل بگیرد.

405 به کلاینت می‌گوید «من می‌دانم چه می‌خواهی، اما این کار را این‌طور نمی‌پذیرم». راه‌حل، تغییر روش درخواست است نه تغییر آدرس.

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

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

  • لایه وب‌سرور: Nginx یا Apache قبل از رسیدن به PHP، درخواست را رد می‌کند (به‌خاطر قواعد rewrite یا محدودیت متد).
  • لایه اپلیکیشن: کد PHP، فریم‌ورک یا API، منبع را می‌شناسد اما متد درخواستی را برای آن پشتیبانی نمی‌کند.
  • لایه میان‌راهی: CDN، WAF، پروکسی معکوس یا فایروال سمت ابری، درخواست را بلاک می‌کند (به‌خاطر سیاست امنیتی روی متدها).

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

سیمپتوملایه احتمالیاولین اقدام تشخیصی
همه متدها روی یک مسیر 405 می‌دهندلایه وب‌سروربررسی rewrite rules و method restriction
فقط POST روی یک مسیر 405 می‌دهدلایه اپلیکیشن یا WAFبررسی هدر Allow در پاسخ
درخواست از مرورگر سالم، از سرویس دیگر 405لایه CORS یا میان‌راهیبررسی هدرهای CORS و preflight
405 فقط از بعضی IPهالایه WAF/CDNبررسی سیاست متدهای مجاز در WAF

تفاوت بنیادین 405 با 404، 401 و 501

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

کدمعنانکته کلیدی
401 Unauthorizedهویت تأیید نشدهباید احراز هویت شود
403 Forbiddenهویت تأیید شده اما مجوز کافی نیستاحراز هویت مجدد بی‌فایده است
404 Not Foundمنبع وجود نداردسرور نمی‌داند چه می‌خواهی
405 Method Not Allowedمنبع وجود دارد اما متد پشتیبانی نمی‌شودروش درخواست را تغییر بده
501 Not Implementedسرور متد را اصلاً نمی‌شناسدمشکل در سرور است، نه در کلاینت

این تفکیک در عیب‌یابی حیاتی است. اگر سرور 404 برگرداند، باید در لایه routing و پیکربندی URL دنبال مسئله بگردید. اگر 405 برگرداند، منبع وجود دارد و فقط متد اشتباه است. تفاوت دقیق 401 و 403 را در تفاوت احراز هویت و مجوزدهی و روش رفع 403 را در رفع خطای 403 Forbidden در سرور آورده‌ام. برای 401 هم راهنمای جامع در خطای 401 Unauthorized در سرور موجود است.

در عیب‌یابی HTTP، تفاوت 404 و 405 یک کاراکتر نیست؛ تفاوت بین «چه می‌خواهی؟» و «این‌طور نمی‌شود» است. اگر این دو را اشتباه بگیرید، در لایه‌ای که مشکل نیست، وقت تلف می‌کنید.

هدر Allow: پیام رسمی سرور

طبق RFC 7231، سروری که پاسخ 405 برمی‌گرداند باید هدر Allow را هم ارسال کند تا به کلاینت بگوید چه متدهایی روی این منبع مجازند. فرمت این هدر به این شکل است: Allow: GET, POST, HEAD. کلاینت با دیدن این هدر، می‌فهمد که متد درخواستش معتبر نیست، اما متدهای دیگر ممکن است جواب بدهند.

سه نکته دقیق در این لایه:

  1. نبود Allow، خطای ناقص: اگر سروری 405 برگرداند اما این هدر را نگذارد، پیاده‌سازی احراز هویت شما ناقص است و کلاینت نمی‌داند چه متدهایی مجازند. بعضی فریم‌ورک‌های PHP و بعضی پیکربندی‌های Nginx این هدر را به‌طور خودکار تنظیم نمی‌کنند.
  2. فهرست ناقص: بعضی سرورها همه متدهای پشتیبانی‌شده را در Allow نمی‌آورند و فقط متدهای عمومی (GET, POST) را ذکر می‌کنند. اگر مطمئن نیستید، با تست مستقیم متدهای مختلف، فهرست واقعی را کشف کنید.
  3. Allow در پاسخ 200: بعضی سرورها به‌عنوان قابلیت اضافی، هدر Allow را در پاسخ‌های 200 هم می‌فرستند تا کلاینت بتواند از قبل بداند چه متدهایی مجازند. این کار اختیاری است اما در APIهای عمومی مفید است.

روش تشخیص: با curl -X POST -i https://example.com/path درخواست را بزنید و هدر Allow را در پاسخ ببینید. اگر وجود داشت، فهرست متدهای مجاز را می‌بینید و می‌توانید متد درخواست را تغییر دهید. اصول طراحی REST API و رفتار درست با متدها را در اصول طراحی REST API و REST API چیست آورده‌ام.

متدهای HTTP و معنای دقیق هرکدام

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

متدکاربردSafe / Idempotent
GETدریافت منبعSafe و Idempotent
POSTساخت منبع جدید یا ارسال دادهنه Safe، نه Idempotent
PUTجایگزینی کامل منبعIdempotent
PATCHویرایش بخشی از منبعنه Safe، نه Idempotent
DELETEحذف منبعIdempotent
HEADمثل GET اما بدون bodySafe و Idempotent
OPTIONSدریافت فهرست متدهای مجازSafe و Idempotent

سه سناریوی دقیق که در آن‌ها عدم تطابق متد باعث 405 می‌شود:

  • ارسال POST به مسیر GET-only: اگر یک endpoint را برای دریافت داده طراحی کرده‌اید و کلاینت به‌اشتباه POST می‌فرستد، سرور 405 برمی‌گرداند. این سناریو در مصرف‌کننده‌های API که با مستندات دقیق کار نمی‌کنند، شایع است.
  • OPTIONS در CORS preflight: در درخواست‌های بین‌دامنه‌ای، مرورگر ابتدا یک درخواست OPTIONS می‌فرستد. اگر سرور این متد را روی مسیر مربوطه پشتیبانی نکند، درخواست اصلی (مثلاً PUT یا DELETE) رد می‌شود. این سناریو در APIهای CORS شایع است.
  • HEAD روی مسیر non-GET: بعضی ابزارهای مانیتورینگ و پروکسی‌ها، برای بررسی سلامت مسیر، درخواست HEAD می‌فرستند. اگر سروری این متد را پشتیبانی نکند، 405 برمی‌گرداند. این سناریو در تنظیمات Nginx پیش‌فرض شایع نیست، اما در بعضی پیکربندی‌های سفارشی دیده شده است.

مبانی HTTP و متدهای آن، پایه‌ای است که هر توسعه‌دهنده وب باید بداند. برای درک عمیق‌تر API و مفاهیم آن، API چیست و چه کاربردی دارد نقطه شروع مناسبی است.

405 در REST API و وردپرس

در دنیای REST API، خطای 405 شایع‌ترین کد خطای «متد» است. هر endpoint در REST، مجموعه‌ای مشخص از متدهای پشتیبانی‌شده دارد که در طراحی مشخص می‌شود. اگر کلاینت متدی غیر از این مجموعه بفرستد، سرور 405 برمی‌گرداند. در وردپرس، REST API از چهار متد اصلی استفاده می‌کند: GET برای خواندن، POST برای ساخت، PUT برای جایگزینی و DELETE برای حذف. هر endpoint ممکن است همه یا بعضی از این متدها را پشتیبانی کند.

سه سناریوی دقیق در REST API وردپرس:

  1. ارسال PUT به‌جای PATCH یا برعکس: بعضی endpointهای وردپرس فقط PUT را می‌پذیرند و PATCH را نه. اگر کلاینت شما PATCH بفرستد، پاسخ 405 می‌گیرد. راه‌حل: مستندات REST API وردپرس را بررسی کنید و متد درست را انتخاب کنید.
  2. درخواست OPTIONS بدون پشتیبانی در سرور: در بعضی پیکربندی‌ها، Nginx یا Apache به‌طور پیش‌فرض OPTIONS را روی مسیرهای REST بلاک می‌کنند. نتیجه: درخواست‌های CORS preflight از اپلیکیشن‌های خارجی شکست می‌خورند و 405 می‌گیرند.
  3. استفاده از GET برای ساخت داده: بعضی توسعه‌دهنده‌ها به‌اشتباه از GET برای ساخت داده استفاده می‌کنند (که هم امنیتی است و هم اشتباه). اگر API وردپرس فقط POST را برای ساخت پشتیبانی کند، GET با 405 رد می‌شود.

روش تشخیص: با curl -X OPTIONS -i https://yoursite.com/wp-json/wp/v2/posts فهرست متدهای مجاز را ببینید. راهنمای کامل REST API وردپرس در API در وردپرس و روش کاربردهای مختلف در استفاده از REST API در وردپرس آمده است. برای درک جایگاه REST در معماری مدرن، تفاوت REST و GraphQL مقایسه دقیقی است.

در REST API، متد HTTP یک قرارداد است، نه یک سلیقه. اگر کلاینت قرارداد را نقض کند، سرور با 405 پاسخ می‌دهد — و این پاسخ، درست و بجاست.

405 در فرم‌های HTML و درخواست‌های POST

فرم‌های HTML از دو متد اصلی پشتیبانی می‌کنند: GET و POST. اگر فرمی با متد POST به یک مسیر ارسال شود که در سرور فقط برای GET تنظیم شده، پاسخ 405 دریافت می‌شود. این سناریو در پروژه‌های وردپرسی شایع است، خصوصاً وقتی که مسیر با یک rewrite rule سفارشی به یک فایل خاص هدایت می‌شود.

سه اشتباه دقیق در این لایه:

  • ناسازگاری متد فرم با مسیر: فرم با method="post" ارسال می‌شود اما مسیر در Nginx فقط برای GET تنظیم شده. راه‌حل: در پیکربندی، متدهای مجاز را گسترش دهید.
  • rewrite rule ناقص: اگر rewrite rule فقط برای GET طراحی شده باشد، POST به یک مسیر rewrite می‌شود که متد را نمی‌پذیرد.
  • افزونه امنیتی روی فرم‌ها: بعضی افزونه‌های امنیتی، ارسال POST به مسیرهای خاص را به‌عنوان «حمله» علامت می‌زنند و 405 برمی‌گردانند. بررسی فهرست exceptionهای افزونه ضروری است.

روش تشخیص: در Network مرورگر، درخواست فرم را ببینید و متد و پاسخ آن را بررسی کنید. اگر POST به 405 رسید، ریشه در لایه سرور یا افزونه است نه در فرم. راهنمای کلی فرم‌ها در وردپرس در پیکربندی ایمیل‌های وردپرس و امنیت فرم‌ها در محافظت از فرم‌ها در برابر CSRF آمده است.

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

Nginx به‌طور پیش‌فرض همه متدهای استاندارد HTTP را می‌پذیرد. اما در پیکربندی‌های سفارشی، بعضی ادمین‌ها برای امنیت یا بهینه‌سازی، متدهای خاص را محدود می‌کنند. سه سناریوی دقیق در این لایه:

  1. محدودسازی متد با if یا limit_except: اگر در پیکربندی Nginx از بلوک limit_except GET { deny all; } استفاده شده باشد، فقط GET مجاز است و بقیه متدها 405 می‌گیرند. راه‌حل: فهرست متدهای مجاز را گسترش دهید یا بلوک را با دقت تنظیم کنید.
  2. rewrite rule با متد محدود: بعضی rewrite ruleهای سفارشی، فقط برای GET یا POST طراحی شده‌اند و بقیه متدها را نادیده می‌گیرند. نتیجه: درخواست در لایه rewrite به 405 می‌رسد.
  3. mod_security یا ماژول امنیتی: ماژول‌های امنیتی Nginx ممکن است روی متدهای خاص قواعد محدودکننده داشته باشند. بررسی لاگ این ماژول‌ها، ریشه را نشان می‌دهد.

روش تشخیص: فایل پیکربندی Nginx (معمولاً در /etc/nginx/sites-enabled/) را باز کنید و بلوک‌های location را برای کلمات limit_except، if ($request_method و deny جست‌وجو کنید. برای بازبینی عمیق‌تر لاگ‌ها، بررسی خطاهای سرور در لاگ‌ها راهنمای دقیقی است. برای دستورات ضروری مدیریت سرور، دستورات ضروری CLI نقطه شروع مناسبی است.

405 در Apache و htaccess

در Apache، محدودسازی متد معمولاً از طریق بلوک <Limit> یا <LimitExcept> در فایل پیکربندی یا .htaccess انجام می‌شود. سه سناریوی دقیق:

  1. بلوک Limit در htaccess: اگر فایل .htaccess شامل <Limit POST> deny from all </Limit> باشد، همه درخواست‌های POST به 405 یا 403 می‌رسند. تفاوت بین 403 و 405 بستگی به پیاده‌سازی Apache دارد.
  2. mod_rewrite با محدودیت متد: اگر rewrite rule روی شرط RewriteCond %{REQUEST_METHOD} تنظیم شده باشد، متدهای غیرمجاز به مسیر اشتباهی هدایت می‌شوند و نتیجه 405 یا 404 است.
  3. mod_security با قواعد سفارشی: ماژول امنیتی Apache ممکن است روی متدهای خاص قواعد محدودکننده داشته باشد. بررسی لاگ mod_security، ریشه را نشان می‌دهد.

روش تشخیص: با apachectl -t صحت فایل پیکربندی را بررسی کنید. سپس .htaccess را برای کلمات Limit، LimitExcept و REQUEST_METHOD جست‌وجو کنید. برای امنیت سرور Apache، امنیت سرور چه اصولی دارد راهنمای دقیقی است.

405 در CDN، WAF و پروکسی معکوس

در معماری‌های مدرن، درخواست‌ها ابتدا از CDN و WAF عبور می‌کنند. اگر این لایه‌ها، متد HTTP را به‌عنوان «مشکوک» یا «غیرمجاز» تشخیص دهند، ممکن است 405 برگردانند حتی اگر اپلیکیشن شما سالم باشد. سه سناریوی دقیق:

  • WAF با سیاست متد: بعضی WAFها، به‌طور پیش‌فرض فقط GET و POST را می‌پذیرند و PUT، PATCH و DELETE را برای endpointهای عمومی بلاک می‌کنند. این سناریو در APIهای مدرن که از PUT استفاده می‌کنند، شایع است.
  • CDN با محدودیت متد: بعضی CDNها برای کش‌کردن بهینه، متدهای غیر GET را محدود می‌کنند و 405 برمی‌گردانند.
  • پروکسی معکوس با سیاست امنیتی: بعضی پروکسی‌های معکوس، برای کاهش سطح حمله، متدهای PUT و DELETE را بلاک می‌کنند.

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

405 در CORS و درخواست‌های بین‌دامنه‌ای

در درخواست‌های بین‌دامنه‌ای، مرورگر ابتدا یک درخواست OPTIONS به‌عنوان CORS preflight می‌فرستد تا مطمئن شود سرور، متد اصلی (مثلاً PUT) را می‌پذیرد. اگر سرور به این OPTIONS پاسخ درست (با هدرهای CORS مناسب) ندهد، مرورگر درخواست اصلی را ارسال نمی‌کند و کاربر خطای CORS می‌بیند. اما اگر سرور به OPTIONS پاسخ 405 بدهد، ممکن است پیام دقیق «405 Method Not Allowed» در کنسول نمایش داده شود که فریب‌دهنده است.

سه نکته دقیق در این لایه:

  1. OPTIONS پشتیبانی نمی‌شود: بعضی پیکربندی‌های Nginx یا Apache، OPTIONS را بلاک می‌کنند. نتیجه: CORS preflight شکست می‌خورد و درخواست اصلی هرگز فرستاده نمی‌شود.
  2. هدرهای CORS ناقص: اگر پاسخ OPTIONS بدون هدر Access-Control-Allow-Methods ارسال شود، مرورگر درخواست اصلی را رد می‌کند.
  3. OPTIONS با احراز هویت: بعضی سرورها OPTIONS را فقط برای درخواست‌های احراز هویت‌شده می‌پذیرند، در حالی که CORS preflight ذاتاً بدون credential ارسال می‌شود. نتیجه: 401 یا 405.

روش تشخیص: در Network مرورگر، درخواست OPTIONS و پاسخ آن را ببینید. اصول کلی CORS و رفع خطاهای آن را در رفع خطای CORS در جاوااسکریپت آورده‌ام.

در معماری‌های مدرن، خطای CORS و 405 اغلب با هم اشتباه گرفته می‌شوند. تفکیک آن‌ها در کنسول مرورگر، اولین قدم برای رفع درست است.

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

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

  1. عدم تطابق متد: کلاینت متدی می‌فرستد که endpoint پشتیبانی نمی‌کند.
  2. rewrite rule ناقص: قواعد rewrite که فقط برای یک متد خاص طراحی شده‌اند.
  3. محدودسازی متد در وب‌سرور: بلوک limit_except در Nginx یا Limit در Apache.
  4. WAF با سیاست متد: بعضی فایروال‌ها PUT و DELETE را بلاک می‌کنند.
  5. CDN با محدودیت متد: بعضی CDNها متدهای غیر GET را محدود می‌کنند.
  6. افزونه امنیتی: بعضی افزونه‌های امنیتی، متدهای خاص را روی مسیرهای خاص بلاک می‌کنند.
  7. CORS preflight شکست‌خورده: OPTIONS بدون پاسخ درست، باعث شکست درخواست اصلی می‌شود.
  8. پروکسی معکوس با سیاست متد: بعضی پروکسی‌ها متدهای PUT و DELETE را برای کاهش سطح حمله بلاک می‌کنند.
  9. تنظیمات اشتباه REST API: endpoint با متد اشتباه درخواست می‌شود.
  10. مشکل در احراز هویت که به‌اشتباه 405 می‌شود: بعضی پیاده‌سازی‌های غیر استاندارد، در صورت نبود احراز هویت روی متدهای خاص، 405 برمی‌گردانند.

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

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

  1. بازتولید و ثبت دقیق: با curl -X POST -i https://example.com/path درخواست را بزنید و همه هدرهای ارسال و دریافت را ثبت کنید. اولین قدم برای تشخیص لایه، دیدن این هدرهاست.
  2. بررسی هدر Allow: در پاسخ، هدر Allow را ببینید. اگر وجود دارد، فهرست متدهای مجاز را می‌بینید و می‌توانید متد درخواست را تغییر دهید.
  3. بررسی لاگ سرور: در /var/log/nginx/error.log یا /var/log/apache2/error.log، آخرین درخواست‌ها و خطاهای مرتبط را ببینید.
  4. بررسی پیکربندی وب‌سرور: فایل Nginx یا Apache را برای بلوک‌های limit_except، Limit و REQUEST_METHOD جست‌وجو کنید.
  5. بررسی .htaccess: اگر روی Apache هستید، فایل .htaccess را برای محدودیت متد جست‌وجو کنید.
  6. تست با متد دیگر: با curl -X GET یا curl -X OPTIONS به همان مسیر درخواست بزنید. اگر پاسخ متفاوت بود، ریشه در لایه وب‌سرور یا rewrite است.
  7. بررسی لاگ CDN و WAF: اگر از CDN استفاده می‌کنید، لاگ آن را بررسی کنید که آیا درخواست به سرور اصلی رسیده یا بلاک شده.
  8. غیرفعال‌سازی افزونه‌های امنیتی روی استجینگ: اگر افزونه امنیتی به‌تازگی نصب شده، احتمال تداخل روی متدها وجود دارد.
  9. تست CORS در مرورگر: اگر درخواست از دامنه دیگر می‌آید، کنسول مرورگر را باز کنید و خطای preflight را ببینید.
  10. بررسی مستندات API: اگر روی REST API کار می‌کنید، مستندات را برای متدهای مجاز هر endpoint بررسی کنید.

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

در عیب‌یابی 405، اولین کار این نیست که پیکربندی سرور را عوض کنم. اولین کار این است که با curl -X OPTIONS فهرست متدهای مجاز را ببینم و سپس تصمیم بگیرم که آیا مشکل در کلاینت است یا در سرور.

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

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

  • اشتباه گرفتن 405 با 404: اگر سرور 405 برگرداند اما شما در لایه routing و URL جست‌وجو کنید، وقت تلف می‌شود. 405 به‌معنای «متد اشتباه» است، نه «آدرس اشتباه».
  • غیرفعال کردن فایروال برای «رفع سریع»: این کار مشکل را موقتاً حل می‌کند اما سایت را در برابر حملات باز می‌گذارد. راه‌حل درست: تنظیم دقیق سیاست متدها، نه غیرفعال کردن.
  • نادیده گرفتن هدر Allow: نبود این هدر در پاسخ 405، یک سیگنال مهم است که اغلب دیده نمی‌شود.
  • تغییر همزمان پیکربندی سرور و CDN: اگر همزمان Nginx و CDN را تغییر دهید، نمی‌دانید کدام مؤثر بوده. یک تغییر، یک تست.
  • بی‌توجهی به preflight در CORS: اگر درخواست از دامنه دیگر می‌آید، ابتدا OPTIONS را بررسی کنید. بی‌توجهی به این لایه، می‌تواند به ساعات عیب‌یابی اشتباه منجر شود.

پرسش‌های پرتکرار درباره خطای 405 Method Not Allowed

405 Method Not Allowed با 404 Not Found چه تفاوتی دارد؟ 404 به‌معنای «منبع وجود ندارد» است، در حالی که 405 به‌معنای «منبع وجود دارد اما متد HTTP که فرستادی پشتیبانی نمی‌شود». در 404، آدرس اشتباه است؛ در 405، آدرس درست است اما متد اشتباه.

چرا خطای 405 در پاسخ، هدر Allow ندارد؟ طبق RFC، سرور موظف است این هدر را ارسال کند. نبود آن، نشانه پیاده‌سازی ناقص است. در فریم‌ورک‌ها و پیکربندی‌های سفارشی، این اتفاق شایع است. برای رفع، باید در کد اپلیکیشن یا پیکربندی سرور، هدر Allow را تنظیم کنید.

چرا درخواست من از مرورگر سالم است اما از یک اسکریپت پایتون 405 می‌گیرد؟ احتمالاً اسکریپت شما از متد متفاوتی استفاده می‌کند (مثلاً PUT یا DELETE) که از مرورگر ارسال نمی‌شود. تفاوت متد را در دو حالت بررسی کنید و متد اسکریپت را با فهرست Allow تطبیق دهید.

چرا CORS در درخواست‌های بین‌دامنه‌ای باعث 405 می‌شود؟ در CORS، مرورگر ابتدا OPTIONS می‌فرستد. اگر سرور این متد را پشتیبانی نکند یا پاسخ درست با هدرهای CORS ندهد، مرورگر درخواست اصلی را ارسال نمی‌کند و ممکن است پیام 405 نمایش دهد. راه‌حل: پشتیبانی از OPTIONS و ارسال هدرهای CORS مناسب.

چرا سرور بعد از مهاجرت به CDN شروع به 405 دادن کرد؟ بعضی CDNها برای بهینه‌سازی کش، متدهای غیر GET را بلاک می‌کنند. تنظیمات CDN را بررسی کنید و در صورت لزوم، سیاست متد را گسترش دهید.

چرا خطای 405 فقط از بعضی IPها رخ می‌دهد؟ این نشانه سیاست محدودیت جغرافیایی یا IP در WAF یا CDN است که روی متدهای خاص اعمال می‌شود. لاگ CDN را بررسی کنید و مطمئن شوید IP مشتری در لیست سیاه نیست.

چطور بفهمم کدام متد برای یک مسیر پشتیبانی می‌شود؟ با curl -X OPTIONS -i https://example.com/path درخواست بزنید و هدر Allow را در پاسخ ببینید. اگر پاسخ OPTIONS نداشت، با curl -X GET -i و curl -X POST -i تست کنید و از فهرست پاسخ‌ها متدهای مجاز را کشف کنید.

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

چرا بعد از نصب افزونه امنیتی، فرم‌ها 405 می‌گیرند؟ بعضی افزونه‌های امنیتی، POST به مسیرهای خاص را به‌عنوان «حمله» علامت می‌زنند و 405 برمی‌گردانند. مسیر فرم را در لیست سفید افزونه قرار دهید.

چطور از بروز 405 در آینده پیشگیری کنم؟ سه اصل: (۱) در هر API، مستندات دقیق متدهای مجاز داشته باشید؛ (۲) بعد از هر تغییر در پیکربندی سرور یا CDN، همه متدهای اصلی (GET, POST, PUT, DELETE, OPTIONS) را تست کنید؛ (۳) لاگ دقیق درخواست‌های رد‌شده در وب‌سرور داشته باشید تا ترند را ببینید.

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

چرا در WordPress REST API، بعضی endpointها با PUT کار می‌کنند و با POST نه؟ در طراحی REST، PUT برای جایگزینی کامل منبع و POST برای ساخت منبع جدید استفاده می‌شود. هر endpoint ممکن است یکی یا هر دو را پشتیبانی کند. برای رفع، مستندات REST API وردپرس را بررسی کنید یا با OPTIONS فهرست متدهای مجاز را ببینید.

آنچه از این مسیر با ما می‌ماند

خطای 405 Method Not Allowed در ظاهر یک پیام ساده است؛ در عمل، یک چالش درباره «روش درخواست» که در یکی از چند لایه ممکن است شکل گرفته باشد. سه اصل که از این مسیر با من می‌ماند:

  1. اول هدر Allow را بخوان، بعد تصمیم بگیر: این هدر، فهرست متدهای مجاز را مستقیم از سرور می‌گوید. با خواندن آن، می‌فهمید که ریشه در کلاینت است یا در سرور، و دیگر لازم نیست در لایه اشتباه وقت تلف کنید.
  2. یک لاگ مرکزی برای درخواست‌های رد‌شده: در هر سرویس، یک لاگ دقیق از درخواست‌های رد‌شده در لایه وب‌سرور داشته باشید. این لاگ، ترند خطاها را نشان می‌دهد و پیش از بحران، ریشه را آشکار می‌کند. اصول ثبت لاگ سرور را در بررسی خطاهای سرور در لاگ‌ها آورده‌ام.
  3. مستندسازی متدهای هر endpoint: برای هر endpoint در API، یک برگه کوچک بسازید که متدهای مجاز، محدودیت‌ها و شرط‌های احراز هویت را ثبت کند. این سند، در روزهای بعدی، سرمایه شماست و از بروز 405 در مصرف‌کننده‌های API جلوگیری می‌کند.

اگر در پروژه‌ای با مشکل 405 دست‌وپنجه نرم کرده‌اید، برای من جالب است بدانم کدام لایه بیشترین وقت شما را گرفت: پیکربندی Nginx، Apache، WAF یا REST API. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر نشانه‌ای کشف کرده‌اید که در این فهرست نبوده. همین نشانه‌ها، دقیق‌ترین راهنمای نفر بعدی‌اند. 🚦