在一个页面上，我正在进行多个AJAX调用。所有调用都成功返回响应，但最后一个调用（与其他ajax调用无关）返回500内部服务器错误作为响应代码（如firebug所述）。但是，尽管存在错误代码，但从该AJAX调用返回了正确的内容。
令我惊讶的是，当我将php.ini中的display_errors选项设置为On时，错误消失并在页面上呈现响应。我已将设置错误记录到文件，但没有记录与上述内部服务器错误相对应的错误。
顺便说一句，我使用Apache，JQuery，PHP5，APC（如果它是相关的）。
鉴于可用信息有限，最可能的答案是PHP在完成回显预期输出后达到致命错误。
测试：在最后执行的行中，回显一些东西。如果没有显示回声，那么您就知道您的PHP脚本正在停止某个地方。那时，这只是调试和跟踪的问题。
这很奇怪......你使用某种类型的库或其他未编写的代码可能会影响状态代码头而不依赖于实际的返回值吗？
我有这个完全相同的问题，结果是一个隐藏的致命错误。打开display_errors，查找错误，粉碎错误，关闭display_errors（可能最好保持display_errors开启以进行开发和关闭生产）。
在这一个请求中，PHP解释器只是崩溃了。我知道可能导致PHP崩溃的一个潜在原因：
由于GCC 4.3中的一些错误，使用此版本的编译器编译的PHP具有异常的实现。在某些非平凡的情况下，脚本抛出异常会导致段错误并终止脚本执行。几个月前，PHP团队证实了这一论点。
要验证是否发生了这种情况，您只需检查脚本执行崩溃的位置，如果在抛出异常后发生，您就在家。检查可以通过在脚本中进一步放置die()来完成，看看会发生什么。另一种方法是使用declare(ticks=1)并注册一个tick函数，它将debug_backtrace()中的最后一个条目保存到每个tick的文件中，这样你就可以获得一个报告，如何执行脚本。
我有一些类似的问题，问题是脚本抛出异常并且没有catch块，因此异常会冒泡到表面并且发生致命错误“未捕获的异常”。这是标准的PHP行为，但在一个特定的服务器上，你也会得到500内部服务器错误而不是200 OK的响应代码。删除异常并用die（）语句替换它们修复了该服务器上的问题（我们可以这样做，因为它是一个简单的脚本，实际上并没有从异常中受益）
这个问题通常由以下因素决定。检查脚本权限，权限和所有权。如果在ajax调用后返回，请检查是否存在致命错误。检查您是否在ASCII模式下意外地将文件上传到Unix。
更多信息可以在http://www.larshemel.com/forum/500_internal_server_error阅读