WordPress AJAX请求超长导致302重定向解决方案

当你通过 WordPress 的 admin-ajax.php 发起一个体积较大的 AJAX 请求时，比如 POST 数据超过了 300KB，结果服务器没有按预期返回 200 响应，反而给了一个 302 重定向。这听起来有点诡异，但别慌，问题的根源通常不在 WordPress 本身，而是 PHP 或服务器的默认配置在背后“作梗”。下面我们会给出一套立竿见影的配置调整方案和稳健的开发实践建议。

在共享主机环境下，当 AJAX 请求因数据量过大（例如超过 300KB）而返回 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，可以尝试在 WordPress 层面通过代码动态设置：

// 在 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 文件，可在网站根目录的 .htaccess 中添加以下内容：

  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

方案三：通过 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 调试日志（在 wp-config.php 中添加 define('WP_DEBUG_LOG', true);），然后查看 wp-content/debug.log 文件。同时，务必检查服务器错误日志，在 cPanel 中通常可通过 "Errors" 或 "Metrics → Error Logs" 找到。

总结

解决大体积 AJAX 请求返回 302 问题的核心思路，在于解除 PHP 层对 POST 数据的硬性限制。优先推荐使用 cPanel 的 PHP 配置工具，因其可全局生效；若此路径不可行，再考虑 ini_set() 或 .htaccess 方案。不过，从长远角度出发，将请求重构为分块传输并配合前端进度反馈，才是兼顾性能、可靠性和用户体验的最佳实践。你说呢？