PHP+IIS表单提交报错：临时文件创建/头部已发送，求排查方向

在PHP 7.2.29 + Windows Server 2012 R2 + IIS 8.5的环境下，遇到表单提交后丢失POST变量还报临时目录相关错误的情况，除了你已经调整的配置，还有这些可以排查的方向：

• 检查PHP临时目录配置与权限
  错误提示里的*"file created in the system's temporary directory"*是关键线索——PHP处理POST数据时可能需要临时存储，但默认系统临时目录（如C:\Windows\Temp）的权限可能不满足IIS应用池身份的读写需求：

  • 先在正常运行的页面（比如单独的phpinfo页面）查看upload_tmp_dir的实际值，如果为空则使用系统默认目录；
  • 给IIS应用池对应的身份（通常是ApplicationPoolIdentity）赋予该临时目录的写入、修改权限；
  • 也可以手动指定一个权限可控的目录，在php.ini中设置：upload_tmp_dir = "D:\PHP_Temp"，设置后重启IIS和PHP服务。

• 调整IIS请求筛选的内容长度限制
  你已经配置了URL和查询字符串长度，但POST请求的内容长度限制也可能拦截大体积的表单数据：

  1. 打开IIS管理器，找到目标服务器或站点→请求筛选→请求限制；
  2. 点击「编辑功能设置」，将*"Maximum allowed content length"*调大（比如设为524288000，对应500MB），确保和post_max_size的配置值匹配。

• 统一PHP的POST相关配置
  虽然你设置了post_max_size = 512M，但要确保upload_max_filesize也同步调整，避免配置不匹配导致的隐性限制：
  在php.ini中设置：upload_max_filesize = 512M，重启服务后验证生效情况。

• 查看详细日志定位问题
  页面上的错误提示信息有限，建议查看两类日志：

  • IIS日志：默认路径为C:\inetpub\logs\LogFiles，找到对应请求时间的日志条目，查看状态码（比如4xx错误意味着请求被IIS拦截）；
  • PHP错误日志：在php.ini中开启详细日志：

    log_errors = On
    error_log = "D:\PHP_Logs\php_error.log"
    error_reporting = E_ALL
    

    提交表单后查看日志，能获取到临时目录写入失败或变量处理异常的具体原因。

• 检查IIS应用池的相关设置
  大体积的POST请求可能触发应用池的保护机制：

  • 打开IIS管理器→应用池→目标应用池→高级设置；
  • 临时禁用「快速失败保护」（仅测试用），或者调大「失败次数」；
  • 适当增大「队列长度」（默认1000，可尝试调到2000），避免请求因队列满被拒绝。

• 验证max_input_vars的实际生效值
  虽然你设置了max_input_vars = 100000，但可能存在配置未生效或被覆盖的情况：
  在postpage.php中添加代码：echo ini_get('max_input_vars');，访问页面确认实际生效的数值，确保它大于表单的变量总数（你的表单是900个，理论上远低于设置值，但还是要确认）。

• 检查系统临时目录的磁盘状态
  如果使用系统默认临时目录，还要确认：

  • 磁盘剩余空间是否充足，避免因空间不足导致临时文件创建失败；
  • 该目录是否开启了磁盘配额，限制了IIS应用池用户的可用空间。

内容的提问来源于stack exchange，提问作者Beauvais