Android使用Volley连接MS Sql时出现服务器错误

这种情况我之前排查过好几次，大概率是IIS对请求头的解析逻辑或者PHP的配置限制导致的——毕竟Postman能正常请求，说明接口本身没问题，问题出在Android端发送的请求和IIS/PHP的兼容上。下面给你几个必调的配置点，以及排查思路：

1. 检查IIS的请求筛选规则 #

IIS默认会对请求头做一些限制，可能是它把Volley发送的Content-Type: application/x-www-form-urlencoded头判定为非法了：

• 打开IIS管理器，找到你的目标站点，双击「请求筛选」
• 切换到「HTTP头」标签页，先确认Content-Type头在「允许的HTTP头」列表里；如果不在，点击右侧「添加」按钮，输入Content-Type并保存
• 另外检查「拒绝的HTTP头」里有没有相关规则，如果有直接删除
• 还可以尝试开启「允许未列出的HTTP头」（不推荐长期开启，但可以用来快速验证问题）

2. 调整PHP的php.ini配置 #

当请求头带application/x-www-form-urlencoded时，PHP需要正确读取POST数据，以下两个配置要确认：

• 找到enable_post_data_reading = On，确保这个选项是开启的（默认应该是开的，但有时候部署时会被误改）
• 检查post_max_size和upload_max_filesize，如果你的请求数据量超过了这两个值的限制，也会触发服务器错误（不过你Postman能正常请求，这个概率相对低，但可以顺手排查）

3. 排查FastCGI和URL重写设置 #

如果你的PHP是通过FastCGI运行在IIS上，还有两个细节要注意：

• 打开IIS的「FastCGI设置」，找到对应的PHP应用池，右键选择「编辑」，在「传递环境变量」里确认是否包含CONTENT_TYPE相关的变量；如果没有，添加一个键为CONTENT_TYPE、值为空的变量（让IIS把请求头传递给PHP）
• 如果你用了URL重写规则，检查规则是否无意中修改或丢弃了Content-Type头——可以暂时禁用重写规则测试，如果恢复正常，就需要调整规则逻辑

额外调试技巧 #

• 在你的PHP接口开头加一行代码打印所有请求头：print_r(getallheaders());，然后分别用Volley（带Content-Type头）和Postman请求，对比两者的头差异，能快速定位问题
• 查看IIS的日志文件（默认路径C:\inetpub\logs\LogFiles），里面会记录具体的错误状态码和详细原因，比如是400（请求非法）还是500（服务器内部错误），能帮你缩小排查范围

简单来说：如果你不想去掉Content-Type头，就必须调整上面的IIS或PHP配置，其中请求筛选和PHP的POST数据读取设置是最可能的症结。

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