Nginx作为一款高性能的HTTP和反向代理服务器,广泛应用于Web服务、负载均衡、静态资源处理等场景，掌握其基本命令是运维和开发人员的必备技能，这些命令涵盖了服务启动、停止、配置重载、日志管理等多个方面，以下将详细介绍Nginx的常用基本命令，并结合实际场景说明其使用方法和注意事项。
Nginx的安装路径和配置文件位置会影响命令的执行方式,在Linux系统中，Nginx的默认安装路径通常为/usr/local/nginx或/etc/nginx，主配置文件一般为nginx.conf，位于conf目录下，执行命令时，若未指定配置文件路径，Nginx会默认使用编译时指定的配置文件，通过cd /usr/local/nginx/sbin进入命令目录后，执行./nginx即可启动服务；若配置文件位于/etc/nginx/nginx.conf，则需通过-c参数指定，如./nginx -c /etc/nginx/nginx.conf。
服务管理是Nginx命令中最基础的部分,启动Nginx服务的命令为nginx或nginx -c [配置文件路径]，若配置文件未放在默认位置，必须通过-c参数明确指定，停止服务则提供了三种方式：快速停止（nginx -s stop）会立即终止所有Nginx进程，可能导致正在处理的请求中断；优雅停止（nginx -s quit）则允许Nginx完成当前请求后再关闭进程，适合生产环境；通过kill命令强制终止进程（如kill -9 [PID]）是最后手段，仅在其他方式无效时使用，重载配置文件是运维中的高频操作，命令nginx -s reload会向Nginx主进程发送USR2信号，主进程会重新加载配置文件并启动新的工作进程，同时旧的工作进程在处理完现有请求后自动退出，实现平滑重启，避免服务中断。
配置文件检查是执行重载或启动前的关键步骤,命令nginx -t用于测试配置文件的语法正确性，它会读取配置文件并检查是否有语法错误或路径问题，输出中包含“syntax is ok”表示语法正确，“test is successful”表示配置可正常加载，若配置文件有误，Nginx会提示具体错误行号和原因，需修复后重新测试，对于调试场景，可通过nginx -T命令显示当前生效的完整配置（包括包含的子配置文件），并输出到终端，便于排查配置问题。
日志管理是Nginx运维的重要环节,默认情况下，Nginx的访问日志位于logs/access.log，错误日志位于logs/error.log，日志级别可通过配置文件中的error_log指令调整，如crit（严重错误）、error（错误）、warn（警告）、info（信息）、debug（调试），生产环境通常建议设置为warn或error以避免日志过多，查看实时日志可使用tail -f logs/access命令，实时监控访问情况，若需轮转日志（避免单个日志文件过大），可通过nginx -s reopen命令向主进程发送USR1信号，Nginx会重新打开日志文件，配合mv命令重命名旧日志文件后，再执行 reopen，即可实现日志分割。
模块和版本信息查询有助于确认Nginx的功能支持,命令nginx -v显示简要的版本信息（如nginx version: nginx/1.18.0），而nginx -V则显示详细版本、编译参数、模块列表等，例如是否包含http_ssl_module、http_gzip_module等，这对于排查依赖问题或确认功能支持至关重要，若需配置HTTPS，必须确保编译时包含http_ssl_module。
进程管理命令涉及对Nginx进程的直接操作,通过ps -ef | grep nginx可查看当前运行的Nginx进程，主进程（master process）负责管理工作进程（worker process），worker进程实际处理客户端请求，若需手动终止某个worker进程，可使用kill命令向其发送信号，如kill -TERM [PID]（优雅终止）或kill -QUIT [PID]（快速终止），但通常不建议直接操作worker进程，而是通过主进程统一管理。
升级Nginx版本时,需使用平滑升级命令，当编译安装新版本Nginx后，执行nginx -s stop停止旧服务，但会导致服务中断；正确做法是先启动新版本Nginx，然后通过kill -USR2 [旧主进程PID]命令，旧主进程会自动执行二进制文件替换，启动新的主进程和工作进程，新旧进程同时运行一段时间后，旧进程会自动退出，实现无缝升级，升级前务必备份旧配置文件，并使用nginx -t测试新版本的配置兼容性。
性能优化相关命令虽不属于Nginx本身,但与运维密切相关，通过worker_processes指令配置worker进程数（通常设置为CPU核心数），worker_connections配置每个进程的最大连接数，总并发能力为worker_processes * worker_connections，调整后需执行nginx -s reload生效，可通过top或htop命令监控Nginx进程的资源占用情况，分析性能瓶颈。
以下为部分常用命令的总结表格：
| 命令功能 | 命令格式 | 说明 |
|---|---|---|
| 启动服务 | nginx / nginx -c [配置文件] | 默认使用编译时配置文件，-c指定自定义配置文件路径 |
| 快速停止 | nginx -s stop | 立即终止所有进程，可能导致请求中断 |
| 优雅停止 | nginx -s quit | 完成当前请求后关闭，生产环境推荐使用 |
| 重载配置 | nginx -s reload | 平滑重启，新配置生效，旧进程处理完请求后退出 |
| 检查配置语法 | nginx -t | 测试配置文件语法，输出成功或失败信息及错误位置 |
| 显示详细配置 | nginx -T | 输出当前生效的完整配置（含子配置），便于调试 |
| 查看版本信息 | nginx -v / nginx -V | -v显示简要版本，-V显示版本、编译参数、模块列表 |
| 轮转日志 | nginx -s reopen | 结合mv命令实现日志分割，需先重命名旧日志文件 |
| 查看进程 | ps -ef | grep nginx | 查看主进程和工作进程的PID及状态 |
| 平滑升级 | kill -USR2 [旧主进程PID] | 启动新版本后，向旧主进程发送USR2信号实现无缝升级 |
在实际使用中,需注意配置文件的权限问题（通常Nginx进程以非root用户运行，需确保配置文件和日志目录对该用户可读可写），以及信号发送的正确性（需确保目标进程PID准确），生产环境中建议使用systemd或supervisor等进程管理工具管理Nginx服务，实现开机自启、自动重启等功能，提高服务稳定性。
相关问答FAQs
Q1: 执行nginx -t显示“test failed”后如何快速定位问题？
A: 首先查看错误日志中的具体错误信息，路径为logs/error.log（或配置文件中error_log指定的路径），常见错误包括配置指令拼写错误、路径不存在（如access_log指定的目录无写入权限）、缺少必要的模块（如未启用http_ssl_module却配置HTTPS）等，可通过nginx -T命令输出完整配置，结合错误日志中的行号，逐行排查配置项，若包含子配置文件（通过include指令引入），需逐一检查子配置文件的语法正确性，修复后重新执行nginx -t，直至测试通过。
Q2: 为什么执行nginx -s reload后，部分请求仍然使用旧配置？
A: nginx -s reload实现平滑重启的原理是：主进程启动新的worker进程加载新配置，旧worker进程继续处理已接收的请求，直到所有请求处理完毕后才退出，在重载后的短时间内，新旧worker进程可能并存，部分请求仍由旧进程处理（使用旧配置），新请求则会由新进程处理（使用新配置），若需确保所有请求立即生效，可等待旧进程自然退出（通过ps -ef | grep nginx观察进程状态），或通过负载均衡器暂时摘除后端服务器，待重载完成后再恢复，若配置中涉及共享内存（如proxy_cache_path），需确保新配置与旧配置的内存区域名称一致，否则需重启服务。
