Nginx在启动或重载时报告unknown directive，表示当前二进制无法在该位置识别这条配置。常见原因是拼写错误、指令放错上下文，或提供指令的模块没有编译或加载。
不要为了恢复服务直接删除不认识的配置行。先判断它承担的访问控制、压缩、脚本或代理功能。
用配置测试锁定文件和行号
执行sudo nginx -t，记录报错中的文件、行号和指令名称；再用sudo nginx -T查看包含文件展开后的完整配置。官方命令行文档说明，-t会检查语法并尝试打开配置引用的文件。
测试时要调用与服务实际相同的nginx二进制和配置前缀。多套安装共存时，手工命令可能检查了另一份配置。
先核对拼写与指令上下文
对照所用版本的官方模块文档确认指令拼写、参数以及允许的main、http、server或location上下文。配置从其他环境复制时，还要核对版本差异。
若指令名称正确但位置不允许，通常会得到指令不允许在此处使用一类错误；unknown directive更应优先检查模块可用性。
确认模块是否编译或加载
运行nginx -V查看版本和构建参数。静态模块需在构建时包含；动态模块则应存在与当前版本兼容的模块文件，并在主配置顶层用load_module加载。
不要从不明来源复制二进制模块。动态模块与Nginx构建不兼容时，可能无法加载；优先使用同一发行版或官方仓库提供的匹配包。
恢复服务并做功能验收
先备份配置，安装或加载正确模块，或按业务意图改用当前版本支持的指令。再次执行nginx -t，通过后才重载；同时保留现有进程和回退路径。
语法通过后还要请求受该配置影响的URL，核对状态码、响应头和错误日志。能够重载不等于原功能仍然生效。
在VPS中复现构建差异
迁移系统或更换软件源时，先在萤光云或LightNode等独立实例对比nginx -V输出。模块清单与配置应作为同一个发布单元管理。
FAQ
问：把unknown directive那一行注释掉就可以吗？答：只有确认该功能不再需要且安全边界不受影响时才可考虑；访问控制和安全模块配置不能草率删除。
温馨提示
温馨提示：重载前始终执行配置测试，并保留旧进程；若测试失败，不要强制替换正在工作的配置。
