nginx -t 报 unknown variable 错误，90% 是因定义变量的 map 块未被加载，需检查 include 路径下文件是否存在、权限是否为644、换行符是否为 Unix 格式，并确保 map 块位于 http 作用域内。
nginx -t 报 unknown variable 时，先盯住 include 路径
宝塔迁移或手动改配置后出现 unknown "connection_upgrade" 这类错误，90% 不是变量写错了，而是定义它的那个 map 块根本没被 Nginx 加载进来。而它通常藏在某个被 include 进来的文件里，比如 /www/server/nginx/conf/websocket.conf 或 /www/server/nginx/conf/enable-php.conf —— 这些文件不会随网站配置一起迁移，但站点的 .conf 文件里却引用了其中定义的变量。
执行 nginx -t 后，错误只说变量不存在，不告诉你缺哪个文件。得自己顺藤摸瓜：
- 打开
/www/server/nginx/conf/nginx.conf，逐行找include语句，例如include /www/server/nginx/conf/vhost/*.conf;或include /www/server/nginx/conf/extra/*.conf; - 对每个
include路径，用ls -l看文件是否存在、是否可读；比如ls -l /www/server/nginx/conf/extra/返回空，就说明这个目录或里面的关键文件缺失 - 重点检查是否漏掉了旧服务器上自定义的全局配置文件（如
websocket.conf），新服务器宝塔默认不生成这类文件 - 如果路径下有文件，用
grep -r "map.*\$http_upgrade" /www/server/nginx/conf/直接搜索定义位置，确认它是否真被包含进来了
include 的文件存在，但 nginx -t 仍报错？检查权限和换行符
文件存在 ≠ Nginx 能读取。宝塔下常见两种静默失败：
-
include的文件权限不对，比如属主是root:root且权限为600，而 Nginx worker 进程以www用户运行，直接跳过加载，也不报错 —— 改成644并确保组可读：chmod 644 /www/server/nginx/conf/extra/websocket.conf - 文件是从 Windows 编辑器保存或复制过来的，含
\r\n换行符，Nginx 解析到一半就中断，导致map块未完整加载 —— 用dos2unix /www/server/nginx/conf/extra/*.conf批量修复，别手动删\r - 注意：宝塔面板“配置检查”按钮调用的也是
nginx -t，但它会静默忽略某些权限/编码问题，命令行执行才暴露真实状态
确认 map 块是否真的在 http 作用域内
$connection_upgrade 必须由 map 指令在 http 块里定义，不能放在 server 或 location 里，也不能放在 events 块之后、http 块之前 —— Nginx 会直接无视。
- 打开你找到的被 include 的文件，确认
map $http_upgrade $connection_upgrade { ... }是直接写在http { ... }大括号内部，而不是嵌套在别的块里 - 如果该文件本身没包
http块（正确做法），那它必须被include在nginx.conf的http块内；如果误加在events块后面、http块前面，Nginx 就当它不存在 - 典型安全写法：
http { include /www/server/nginx/conf/extra/websocket.conf; ... }——include行必须在http {之后、}之前
宝塔迁移后变量缺失，最省事的补救方式
如果你确认是迁移遗漏了 map 定义，又不想翻旧服务器找文件，直接在新服务器 nginx.conf 的 http 块开头手动补上标准定义即可，不用额外建文件：
http {
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
# 后续其他配置...
}这段代码必须放在 http 块最上方（至少要在任何引用 $connection_upgrade 的 server 块之前），且不能缩进到子块里。补完立刻 nginx -t，通过后再重载。别小看这四行 —— 它就是 Nginx 认出那个变量的唯一凭据，缺了就永远报 unknown。
