log_level=10是xdebug排错唯一可信级别，它完整记录dns解析、tcp连接、ssl协商及ide响应等关键路径信息；低于10则裁剪核心过程，无法定位client_host错误或超时根因。
log_level=10 是排错时唯一值得信任的级别
当Xdebug连接失败、断点不触发或页面莫名卡住，xdebug.log_level设得太低（比如默认的0或7）会导致日志里只写“connection failed”，却完全看不到它到底连了谁、什么时候连、为什么超时。只有log_level=10能记录完整握手过程、DNS解析、TCP连接尝试、SSL协商（如果启用）、甚至IDE返回的拒绝响应包内容。
这不是“越详细越好”的权衡，而是必须项：低于10，关键路径信息被直接裁剪；等于10，你才能确认是xdebug.client_host写错了IP，还是xdebug.connect_timeout_ms卡在200ms没等到拒绝就挂起了。
log_level=0 和 log_level=7 的实际差异远超预期
很多人以为log_level=7已经够用，但它只记录错误和警告，不记录连接尝试本身。例如：
-
log_level=0：几乎不输出任何调试行为日志，仅在崩溃时留痕 -
log_level=7：遇到连接拒绝会记一条E: Could not connect to debugging client，但不会告诉你目标地址、端口、重试次数 -
log_level=10：输出类似I: Connecting to configured address/port: 127.0.0.1:9003.和W: Creating socket for '127.0.0.1:9003', poll success, but connection failed.
这意味着，用7级日志排查client_host配成localhost却因DNS解析慢导致超时的问题，你根本看不到DNS那一步——它被静默吞掉了。
log_level=10 日志体积与权限问题必须提前处理
开启log_level=10后，每个HTTP请求可能生成50–200KB日志，尤其在循环调用或API批量请求场景下，/tmp/xdebug.log几秒就能涨到GB级。更隐蔽的问题是权限：
Xdebug 3.4.1 是一款功能强大的 PHP 调试扩展工具，于 2025 年 1 月 6 日正式发布。作为 Xdebug 3.4 系列的首个修复版本，3.4.1 版在继承上一版本强大功能的同时，重点解决了稳定性问题。该版本不仅修复了访问超全局变量时可能引发的程序崩溃现象，还增强了对 Windows 平台 PIE 构建机制的支持，为广大 PHP 开发者提供了更加稳定的调试环境。这一版本适合所有
- PHP-FPM worker进程通常以
www-data或nginx用户运行，不是当前登录用户 - 若
xdebug.log指向/home/user/logs/xdebug.log，大概率写入失败且无提示（日志本身也写不出来） - 日志文件被截断或权限拒绝时，Xdebug会静默放弃写日志，
log_level设置形同虚设
实操建议：sudo mkdir -p /var/log/xdebug && sudo chown www-data:www-data /var/log/xdebug && sudo chmod 755 /var/log/xdebug，再配xdebug.log=/var/log/xdebug/debug.log。
log_level 不影响 xdebug.mode=off 时的日志行为
这是常被忽略的关键点：xdebug.log_level只在Xdebug功能启用时生效。如果xdebug.mode=off，无论log_level设成多少，Xdebug根本不会初始化日志子系统，xdebug.log路径也不会被打开。
换句话说，想靠开日志来“观察Xdebug是否加载”，这个思路是错的。正确做法是先确认phpinfo()里有Xdebug模块信息，再检查xdebug.mode是否至少含debug或develop，否则log_level再高也没用。
真正容易卡住的地方，是开发者一边把xdebug.mode=off当作“禁用调试”，一边又指望log_level=10能输出连接行为——那只会看到空文件，还反复怀疑路径权限问题。
