500错误表示服务端内部异常，需分层排查：先查nginx错误日志（/var/log/nginx/error.log）和后端服务日志，确认是否超时、连接失败或未捕获异常；再验配置语法与逻辑，检查proxy_pass可达性及超时设置；最后查磁盘、inode、文件描述符、内存等资源瓶颈。
500 Internal Server Error 表示 Nginx 或其后端服务在处理请求时发生了未捕获的异常，问题不在客户端，而在服务端执行链的某一层。排查不能只盯着 Nginx 本身，要分层定位、由近及远。
看日志：先确认错误落在哪一层
Nginx 自身不生成业务逻辑错误，它返回 500 通常是因为后端挂了、超时了，或 Nginx 代理过程出问题。所以第一步不是改配置，而是查日志：
-
查 Nginx 错误日志：默认路径
/var/log/nginx/error.log，用tail -f /var/log/nginx/error.log实时观察；重点看报错时间点附近是否有upstream timed out、connect() failed、no live upstreams等关键词。 -
查后端服务日志：比如 PHP-FPM 日志（
php-fpm.conf中error_log指定路径）、Node.js 应用日志、Java 的 catalina.out 等——500 很可能源于后端抛出未捕获异常，Nginx 只是“代为返回”。 -
检查日志是否写入成功：运行
ls -l /var/log/nginx/确认 error.log 文件存在且 Nginx 进程用户（如 www-data）有写权限；若磁盘满或 inode 耗尽（df -i），日志会静默失败，看似“没日志”实则根本没写进去。
验配置：语法正确 ≠ 逻辑安全
配置文件语法无误，不代表运行时不出错。常见隐患包括：
- 用
nginx -t验证语法，再用nginx -s reload平滑重载；若 reload 失败，说明配置虽合法但存在运行时冲突（如端口被占、路径不存在）。 - 检查
proxy_pass地址是否可达：用curl -v http://backend-ip:port/health直连后端，排除网络或服务宕机。 - 确认
fastcgi_pass（PHP）或proxy_read_timeout、proxy_connect_timeout是否过短——后端响应慢，Nginx 就会主动断开并返回 500。
查资源：服务器不是无限兜底的
很多 500 是资源瓶颈触发的静默失败：
-
磁盘空间：
df -h查根分区或日志所在分区；日志轮转失效、大文件堆积都可能导致写入失败。 -
inode 耗尽：小文件过多时
df -i显示 100%，即使磁盘有空余，Nginx 也无法新建临时文件或写日志。 -
文件描述符限制：高并发下可能 hit limit，用
ulimit -n查当前限制，lsof -p $(pgrep nginx) | wc -l查 Nginx 进程已打开数；必要时在nginx.conf加worker_rlimit_nofile 65535;并调整系统 limits.conf。 -
内存与 swap：
free -h和dmesg -T | grep -i "killed process"查是否触发 OOM Killer 杀掉 PHP-FPM 或应用进程。
测链路：绕过 Nginx 直达后端
快速判断是 Nginx 层问题还是后端问题：
- 如果后端是 PHP-FPM，用
curl --unix-socket /run/php/php8.1-fpm.sock http://localhost/health.php直连 socket。 - 如果是 Node.js 或 Java 应用，用
curl http://127.0.0.1:3000/health绕过 Nginx 测试端口连通性与响应内容。 - 若直连正常但经 Nginx 就 500，重点查
proxy_set_header是否丢失关键头（如 Host）、是否因client_max_body_size限制导致 POST 数据被截断、或是否开启proxy_intercept_errors on导致错误页掩盖真实原因。
