405错误表示服务器识别请求路径但拒绝所用HTTP方法，需先查响应头Allow字段确认允许方法，再依次排查真实请求方法、Nginx limit_except配置、后端路由声明、跨域OPTIONS预检及WordPress插件冲突。
当你点击提交按钮后页面突然弹出“405 Not Allowed”，表单卡死、接口调不通、Ajax请求直接中断，说明服务器已明确识别你的请求路径，却因HTTP方法不被允许而当场拒绝——这不是网络断了，也不是权限问题，而是你用的POST/PUT/DELETE被硬性拦截在门外。
确认真实请求方法与服务器允许范围
打开浏览器开发者工具→Network标签页→触发报错操作→找到状态码为405的那条请求→点击它→切换到Headers面板→向下滚动至Response Headers区域→查找【Allow】字段。
如果显示Allow: GET, HEAD，而你发的是POST，问题根源就在这里；若该字段为空或根本没出现，说明405不是来自后端路由逻辑，而是Nginx/Apache/WebDAV等中间层主动拦截。
这一步必须先做，否则所有代码修改都是盲调——很多人坚信自己写了POST，抓包才发现浏览器实际发出的是GET，原因可能是表单漏写method属性、fetch配置被拦截、或重定向过程中方法被降级。
快速验证是否为Nginx配置导致（静态资源场景）
方法一：临时绕过405返回（仅限纯静态HTML/CSS/JS）
登录服务器→用nano编辑站点配置文件（如/etc/nginx/conf.d/default.conf）→在对应server块的location / { }内插入一行：error_page 405 =200 $request_uri;→保存→执行nginx -t验证语法→无误后运行systemctl reload nginx。
方法二：检查limit_except限制
在同一配置文件中搜索limit_except关键字→若存在类似limit_except GET { deny all; }的语句，且业务需要POST提交，必须注释或删除该段→reload生效。
【注意：此方案严禁用于真实API接口，它会掩盖真正的路由缺陷，仅适用于前端静态页内嵌表单提交被误判的紧急恢复场景】
排查后端路由是否缺失对应方法声明
第一步：定位接口控制器文件，找到该URL路径的路由定义位置。
第二步：确认是否显式声明了methods参数。例如Flask中必须写@app.route('/login', methods=['POST'])，若只写@app.route('/login')，默认仅响应GET。
第三步：检查是否有装饰器强制限定方法，比如Django的@require_GET或Spring Boot的@GetMapping——你发POST，它只认GET，必然405。
Express常见错误写法：app.get('/api/submit', handler) → 应改为app.post('/api/submit', handler)或app.all('/api/submit', handler)。
Spring Boot常见错误写法：@GetMapping("/user") → 应改为@PostMapping("/user")或统一用@RequestMapping(value = "/user", method = RequestMethod.POST)。
检查跨域预检OPTIONS是否被拒
如果你的请求带自定义Header、Content-Type为application/json、或使用PUT/DELETE方法，浏览器会在正式请求前自动发一次OPTIONS预检。
此时Network面板会出现两条请求：第一条是OPTIONS 405，第二条灰掉不执行——这说明问题出在预检环节，不是你写的fetch那行代码本身错了。
解决方式：后端需明确响应OPTIONS请求并返回Access-Control-Allow-Methods头，Nginx配置中不能拦截OPTIONS方法，否则整个跨域链路直接断裂。
WordPress插件冲突速查
进入/wp-admin后台→左侧“插件”→点击“已启用”→逐个停用→每停一个就去前台测试表单能否提交成功。
重点排查最近7天内新装的缓存类（如WP Super Cache）、安全类（如Wordfence）、防火墙类（如Sucuri）插件——它们可能悄悄拦截POST请求并返回405，而非记录日志或提示警告。
