WordPress AJAX 请求超长导致 302 重定向的解决办法

当 wordpress 中通过 admin-ajax.php 发起的大体积 ajax 请求（如 post 数据超 300kb）触发 302 重定向而非正常响应时，通常源于 php 或服务器对请求大小、执行时间及输入变量的默认限制。本文提供可立即生效的配置调整与稳健实践建议。

当 wordpress 中通过 admin-ajax.php 发起的大体积 ajax 请求（如 post 数据超 300kb）触发 302 重定向而非正常响应时，通常源于 php 或服务器对请求大小、执行时间及输入变量的默认限制。本文提供可立即生效的配置调整与稳健实践建议。

在共享主机环境下，AJAX 请求因数据量过大（例如 300KB 以上）返回 HTTP 302 状态码而非预期的 200，本质并非 WordPress 主动跳转，而是服务器或 PHP 层因配置限制中断请求后被 Web 服务器（如 Apache/Nginx）或 WordPress 自身安全机制（如未登录用户重定向到登录页）捕获并触发了隐式重定向。根本原因集中在以下三类限制：

? 关键 PHP 配置项解析

需同步调整以下参数（单位：字节或秒），否则单点修改可能无效：

配置项	推荐值	说明
post_max_size	265M	必须 ≥ upload_max_filesize，限制整个 POST 请求体最大尺寸
upload_max_filesize	265M	影响含文件上传的请求，也间接约束纯数据 POST
max_input_vars	8000	防止因数组嵌套过深或字段过多导致参数截断（常见于序列化大数据）
max_execution_time	500	避免脚本超时中断（尤其处理大 JSON 解析或数据库写入时）
max_input_time	-1（或 300）	允许更长时间接收 POST 数据（部分主机不支持 -1，可用 300 替代）
memory_limit	512M	确保反序列化、JSON 解析等操作有足够内存

✅ 实施方案（按优先级排序）

方案一：通过 wp-config.php 或主题 functions.php 动态设置（无需权限）

适用于无法修改 php.ini 的共享主机：

// 在 wp-config.php 文件末尾（/* That's all, stop editing! */ 上方）添加：@ini_set('post_max_size', '265M');@ini_set('upload_max_filesize', '265M');@ini_set('max_execution_time', '500');@ini_set('max_input_time', '300');@ini_set('memory_limit', '512M');@ini_set('max_input_vars', '8000');

⚠️ 注意：@ini_set() 在某些托管环境（如 Cloudflare 启用“Always Online”或 PHP 运行于 PHP-FPM 模式且 disable_functions 包含 ini_set）下可能失效。

方案二：通过 .htaccess（Apache 环境）

若主机支持 mod_php（非 PHP-FPM），可在网站根目录 .htaccess 中添加：

<IfModule mod_php7.c>  php_value post_max_size 265M  php_value upload_max_filesize 265M  php_value max_execution_time 500  php_value max_input_time 300  php_value memory_limit 512M  php_value max_input_vars 8000</IfModule>

方案三：cPanel → PHP 脚本管理器（推荐共享主机用户）

1. 登录 cPanel → 找到 "MultiPHP INI Editor" 或 "Select PHP Version" → "Switch To PHP Options"
2. 选择当前站点使用的 PHP 版本
3. 找到上述参数，逐一修改为推荐值 → 点击 "Apply"
4. 清除 OPcache（如有）并测试

? 重要注意事项

• 302 不是错误，而是信号：它表明请求未被 WordPress 正常处理，极可能是 PHP 因 post_max_size 不足直接丢弃请求体，导致 $_POST 为空，进而触发 WordPress 默认登录重定向逻辑（如 admin-ajax.php 要求管理员权限但会话失效）。
• 避免硬编码超大请求：即使配置调高，仍建议前端采用分块（chunking）策略——例如将 300KB 数据拆分为每次 50KB 的多个 AJAX 请求，配合 Promise.all() 合并结果。这更健壮、可监控、易调试。
• 验证生效：创建临时 PHP 文件（如 phpinfo.php），访问 https://yoursite.com/phpinfo.php，搜索对应配置项确认值已更新。
• 日志排查：启用 WordPress 调试日志（define('WP_DEBUG_LOG', true);）并检查 wp-content/debug.log，同时查看服务器错误日志（cPanel 中常位于 "Errors" 或 "Metrics → Error Logs"）。

✅ 总结

解决大体积 AJAX 302 问题，核心在于解除 PHP 层面对 POST 数据的硬性限制。优先使用 cPanel 的 PHP 配置工具全局生效；若不可行，再尝试 ini_set() 或 .htaccess。但长远来看，重构为分块传输 + 前端进度反馈，才是兼顾性能、稳定性与用户体验的最佳实践。