least_conn配置失效主因是非法字符或结构错位，需用cat -a查隐藏符、dos2unix清理编码、确保其独占upstream块首行且不与ip_hash等混用，并通过stub_status和压测验证连接分布。
排查 least_conn 配置中的非法字符干扰，核心是聚焦语法校验、日志反馈和配置加载行为——Nginx 对 least_conn 的位置和上下文极其敏感，任何隐藏字符或结构错位都会直接导致失效或报错，而不是静默忽略。
检查配置文件是否含不可见非法字符
非法字符（如零宽空格、BOM头、全角分号、中文标点、复制粘贴带入的控制符）常导致 Nginx 启动失败或降级为轮询，但错误提示未必明确指向“非法字符”：
- 用
cat -A nginx.conf查看所有不可见字符，重点关注least_conn;行前后是否有^M（Windows 换行）、M-oM-?M-?（BOM）或^@（空字符） - 用
dos2unix nginx.conf清除 Windows 行尾和常见编码污染 - 避免从网页、微信、Word 等富文本环境直接复制配置；手写或从纯文本编辑器（如 vim、nano）粘贴
验证 least_conn 是否被正确识别和启用
即使配置没报错，非法字符也可能让 Nginx 跳过该指令，退回到默认轮询：
- 执行
nginx -t：若返回directive is not allowed here，说明least_conn;不在upstream {后的第一行，或被注释/空行/其他指令隔开 - 检查
error.log中是否有upstream zone "xxx" has no servers或no live upstreams，这可能是least_conn解析失败后整个 upstream 块未被加载 - 临时删掉所有
server行，只留upstream test { least_conn; }，再运行nginx -t—— 若仍报错，基本可定位为该行本身含非法字符
确认配置结构无语法冲突
看似合法的写法，可能因隐式冲突让 least_conn 失效：
-
least_conn必须独占一行，且紧贴upstream 名称 {后面，不能有空格、tab、注释或空行间隔 - 同一
upstream块中不能出现ip_hash、hash $arg_id、least_time等互斥指令，否则整个 upstream 加载失败 - 禁用
weight参数：写server x.x.x.x weight=2;不报错但会被静默忽略；若误以为它起作用，实际调度逻辑已偏离预期
用 stub_status 实时验证行为是否生效
最终判断不靠配置是否存在，而看连接数分布是否真实响应变化：
- 启用
stub_status，访问/nginx_status，观察各server的Active connections数值 - 用
ab -n 100 -c 10 http://your-domain/施加轻量压测，看活跃连接是否明显偏向某一台（轮询特征）还是动态向连接数低的节点偏移（least_conn 特征） - 若所有节点连接数始终接近且无波动，大概率
least_conn未生效，应回溯前几步排查字符与结构问题
