好久没打开php的项目了，php、nginx、项目，phpfpm都看了，但是浏览器访问一直502，自己找了好久也没有找到原因，也问了豆包，用了命令行工具qwen code。但是没有什么用，让claude code帮忙排查了一下，前后花了20分钟，做了大量的尝试，终于发现是代理问题。下面的内容也是claude code把排查经历以第一人身记录下来了，像AI致敬，像Claude Code致敬
序章：那个令人抓狂的502
"又是502 Bad Gateway！"我盯着浏览器，感觉血压在飙升。
这是一个看似简单的任务：在本地Mac上搭建一个PHP项目，通过demo.crmeb.com域名访问。理论上应该一帆风顺，但现实却给了我一个响亮的耳光。
最诡异的是，所有的日志文件——Nginx日志、PHP日志、项目日志——全都是空的。就像有人悄悄把所有的错误信息都藏起来了。
第一幕：常规排查的失败
我开始按照教科书式的排查流程：
- 检查hosts文件 ✅ 正常
- 检查Nginx配置 ✅ 看起来没问题
- 检查PHP-FPM状态 ✅ 服务在运行
- 检查文件权限 ✅ 都有读写权限
但502错误依然顽固地站在那里，像一堵无形的墙。
我开始怀疑人生："难道请求去了平行宇宙？"
第二幕：深入配置的迷宫
我决定深入检查服务配置，发现了一些可疑的地方：
- PHP-FPM配置的用户是
_www，但实际运行用户是我的用户名 - 工作目录路径可能需要调整
- 可能有多个服务实例在冲突
于是我开始修复：
# 修改PHP-FPM配置
user = wangguodong
group = staff
chdir = /Users/cat/Desktop/CRMEB/crmeb/public
# 清理冲突进程
pkill -9 nginx
pkill -9 php-fpm
# 重新启动服务
nginx
php-fpm -D
满怀期待地刷新页面...依然是502。
第三幕：意外的发现
在绝望中，我决定用curl测试一下：
curl -v http://demo.crmeb.com/test.php
输出让我震惊：
* Uses proxy env variable http_proxy == 'http://127.0.0.1:7890'
* Trying 127.0.0.1:7890...
* Connected to 127.0.0.1 (127.0.0.1) port 7890
< HTTP/1.1 502 Bad Gateway
原来如此！ 所有的请求都被代理服务器拦截了！
第四幕：绕过代理的胜利
我尝试绕过代理：
curl --noproxy '*' http://demo.crmeb.com/test.php
然后，奇迹发生了：
< HTTP/1.1 200 OK
< Server: nginx/1.29.3
< X-Powered-By: PHP/7.4.33
成功了！ PHP页面正常显示了！
反思：我们学到了什么
1. 代理是隐形的杀手
这次故障教会我：永远先检查系统代理设置。代理就像隐形眼镜，平时感觉不到它的存在，但一旦出问题，整个视野都会扭曲。
2. 日志为空是个危险信号
当所有日志都为空时，意味着请求根本没有到达目标服务。这时候应该立即怀疑网络层的问题，而不是在应用层浪费时间。
3. 工具的选择很重要
- curl的
--noproxy参数是排查代理问题的利器 - 浏览器和命令行工具可能使用不同的代理设置
- 有时候最简单的工具能解决最复杂的问题
4. 分而治之的排查策略
- 网络层：代理、DNS、hosts文件
- 服务层：Nginx、PHP-FPM状态
- 应用层：PHP代码、文件权限
按照这个顺序排查，可以避免很多不必要的弯路。
技术要点总结
快速诊断代理问题
# 检查当前代理设置
echo $http_proxy
echo $https_proxy
# 绕过代理测试
curl --noproxy '*' http://your-domain.com
# 或者临时禁用代理
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
永久解决方案
在~/.zshrc或~/.bash_profile中添加：
export no_proxy="localhost,127.0.0.1,*.local"
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
结语
这次502错误的排查经历让我明白：有时候问题不在你看得见的地方，而在那些你以为理所当然的"基础设施"里。
代理设置、网络配置这些看似简单的东西，往往是最容易被忽略的故障点。下次遇到类似问题，我会先问自己："是不是有什么东西在中间拦截了我的请求？"
希望我的经历能帮助其他开发者少走一些弯路。记住，当所有常规方法都失败时，不妨检查一下那些"隐形"的配置。
博客结束
"在技术的世界里，最危险的不是你不知道的东西，而是你以为你知道的东西。"
相关资源
