简介这是面向媒体直播与流媒体运维场景的 Nginx 定制版资源包对应 Nginx 1.7.11.3 Gryphon 版本重点强化了与 FFmpeg 的集成可用于搭建 RTMP、HLS、DASH 等协议的直播服务。包内共 126 个文件约 46.82MB除核心 c/h 源码外还包含 conf 配置模板、html 演示页面、js/swf 前端组件以及 exe/vim/lua 等辅助工具其中 conf 模板可直接用于修改 server 块与 RTMP 块html 页面便于验证播放效果js/swf 组件可作为前端播放器参考覆盖从源码阅读到部署配置的完整链路。目前已有 856 人学习下载。通过该资源用户可了解事件驱动架构在 Nginx 1.7 系列中的实现方式学习 Nginx-RTMP、HLS、DASH 模块的配置逻辑并结合 FFmpeg 进行推流、切片与拉流的实际操作。压缩包内还提供多个 license、readme 与说明文档便于核对版本信息、梳理二次开发注意事项同时可参考配置模板和演示页面快速定位直播服务搭建中的常见问题适合具备一定 Nginx 基础、希望深入媒体服务定制的中高级运维或开发人员。1. 拿到压缩包之后先别急着解压1.1 版本号与构建标识里藏着多少信息先别双击也别一上来就用tar或者右键解压。文件名nginx_1.7.11.3_Gryphon.zip里面有三段关键信息nginx说明软件本体1.7.11.3是版本号Gryphon是一个构建代号。先说版本号。nginx 的版本号通常由三段组成比如1.26.2。这里出现1.7.11.3这种四段结构说明这个包不是纯官方发布的原始包而是在 1.7.x 主线版本之上又打了补丁或者是某个发行版、云平台做过二次构建的产物。1.7 系列是当年那批较早使用 SPDY 和更灵活 upstream 配置的主线版本放在今天看来已经偏老但如果你拿到的压缩包是内网运维那边统一封装的版本老一点反而是常态很多内部系统求的是稳而不是新。再说Gryphon。这不是 nginx 官方命名的风格官方就是纯粹的数字版本号顶多加-stable或者-mainline这种后缀。出现这种代号要么是某个公司内部发布平台的构建标识要么是某个安全加固发行版的自定义名称。拿到这种包第一步不是解压是去确认这个包是谁给的、有没有校验文件。1.2 先校验再解压避免拿到被改动过的包我在实际工作中处理过不少这种来源不明的压缩包有些是同事从别人机器上拷过来的有些是从某个镜像站下载的。我的习惯是三步走。第一步核对校验和。如果发布方同时提供了sha256sum或者md5sum文件那就用对应命令算一下sha256sum nginx_1.7.11.3_Gryphon.zip把输出的那一长串哈希值和发布方提供的对比完全一致再继续。这一步能避免包在传输过程中被破坏也能防止拿到被植入过代码的版本。如果对方没提供校验文件至少解压之后先跑一遍nginx -V看编译参数确认没有可疑模块。第二步解压后检查目录结构。nginx 不管是哪个版本解压后的布局都差不多nginx_1.7.11.3_Gryphon/ ├── conf/ │ ├── nginx.conf │ ├── mime.types │ └── ... ├── html/ │ ├── index.html │ └── 50x.html ├── logs/ └── temp/如果是 Linux 编译版通常会有sbin/nginxWindows 版则是nginx.exe放在根目录。看到目录结构和你预期不一致比如多了奇怪的脚本或者可执行文件要警惕别直接跑。第三步快速验证版本和配置。解压之后先不启动先看版本信息# Linux ./sbin/nginx -v # Windows nginx.exe -v再检查配置文件语法# Linux ./sbin/nginx -t # Windows nginx.exe -t-t会把你配置文件里的语法错误一次性暴露出来报错会精确到行号这是后续所有操作的安全底线。我当时第一次用 nginx 的时候就是没跑-t直接启动结果报配置错误排查半天发现是分号丢了。2. 安装与启动Windows 和 Linux 两条路2.1 Linux 环境下的安装步骤含离线环境Linux 下拿到这种压缩包有两种处理方式直接用编译后的二进制包或者自己重新编译。.zip后缀在这里稍微有点特殊因为 Linux 下 nginx 包常见的是.tar.gz。如果这是别人帮你打好的包那大概率是编译完直接打包的解压到目标目录就能用。我的推荐路径是放到/usr/local/nginx下unzip nginx_1.7.11.3_Gryphon.zip -d /usr/local/ cd /usr/local/nginx_1.7.11.3_Gryphon/先把目录名简化一下方便后续维护mv /usr/local/nginx_1.7.11.3_Gryphon /usr/local/nginx启动命令/usr/local/nginx/sbin/nginx启动之后立刻确认进程状态ps -ef | grep nginx curl http://127.0.0.1/能看到Welcome to nginx!的 HTML 输出说明已经跑起来了。但这里有个非常常见的问题依赖缺失。如果你拿到的包是二进制编译版运行时报error while loading shared libraries是很常见的事情。用ldd检查动态库依赖ldd /usr/local/nginx/sbin/nginx如果提示缺libpcre.so或者libssl.so之类的库用系统包管理器装对应的库。离线环境就麻烦了得从内网软件源搞到这些rpm包或deb包拷进去没有捷径。如果是自己从源码编译安装依赖是编译前就要装好的。CentOS/RHEL 类的系统yum install -y gcc pcre-devel zlib-devel openssl-develUbuntu/Debian 类apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev然后进入源码目录配置编译参数我建议最简配置也要带这几个模块./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream--with-stream是四层负载均衡用的做 TCP 转发和 MySQL 代理会用到。编译安装make make install开机自启我一般直接写 systemd 服务放在/etc/systemd/system/nginx.service[Unit] Descriptionnginx web server Afternetwork.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s stop PrivateTmptrue [Install] WantedBymulti-user.target然后systemctl daemon-reload systemctl enable nginx systemctl start nginx后续就能用systemctl reload nginx优雅重载配置了。2.2 Windows 版使用细节Windows 下的 nginx 安装几乎零成本解压即用。双击nginx.exe或者命令行启动cd C:\nginx_1.7.11.3_Gryphon start nginx.exe这里有个特别容易踩的坑Windows 下双击启动后那个控制台窗口不能关。关掉窗口 nginx 就停了而且不是优雅退出是直接杀掉。正确做法是用命令启动让它在后台跑控制台窗口可以最小化但别关。还有一个坑是路径不能有中文和空格比如放在C:\Users\张三\nginx下面配置里涉及路径规则就很麻烦。我吃过亏后来一律放到盘符根目录或者纯英文路径下。Windows 下修改了配置之后重载命令是nginx.exe -s reload停止是nginx.exe -s stop优雅停止是nginx.exe -s quit这两个区别很大。stop是立刻终止正在处理的请求直接断quit是等当前请求处理完再退出。Windows 下最常见的启动失败原因是端口被占用。80 端口经常被 IIS 或者 System 进程PID 4占住。排查用netstat -ano | findstr :80如果是 PID 4 占用的多半是 IIS 或者 HTTP.sys 服务可以在服务里停掉 World Wide Web Publishing Service或者直接改 nginx 的 listen 端口。Windows 版 nginx 做反向代理是很实用的场景。比如把 80 端口的请求转发到内网的 Tomcat 或者 TongWeb 应用服务器配置和 Linux 下完全一样我在第 3 章会详细讲。3. 核心配置文件拆解从入门到改得动3.1 配置文件总览与核心概念conf/nginx.conf是 nginx 的核心配置它有一套自己的语法。记住三个关键词就行指令、块、上下文。配置文件长这样worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } }从外到内有三层http块包着server块server块里面是location块。events块和http块是平级的它们都在main上下文里。worker_processes是启动几个 worker 进程一般设成和你机器 CPU 核数相同或者直接写auto让系统自动判断。这个参数影响很大设得太多会白白消耗内存太少碰到大流量时性能起不来。worker_connections表示每个 worker 最大并发连接数。两者相乘再乘以一些系数就是估算的极限并发比如 4 核机器、每进程 1024 连接粗略算就是 4096 并发。3.2 server 与 location路由规则的灵魂server块代表一个虚拟主机。listen是监听端口server_name是域名匹配。一个 nginx 可以配很多个server按域名分发到不同站点。location就是路径匹配规则这里有个经典的匹配优先级很多人一开始会搞混写法含义优先级location /path精确匹配最高location ^~ /static/前缀匹配且不再检查正则高location ~ \.php$正则匹配区分大小写中location ~* \.jpg$正则匹配不区分大小写中location /通用前缀匹配最低实际配置里最常见的坑是正则不生效。比如location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; }如果这个location前面还有一个location /请求如果没有命中正则就会落到通用匹配里导致 PHP 请求被当成静态文件处理。排查思路就是先看请求有没有命中高优先级规则再看正则有没有写对。部署前端项目时try_files是一个非常好用的指令。比如 Vue 或 React 用的 history 路由模式页面跳转是前端路由控制的直接刷新/user/profile这个路径服务器找不到对应文件就返回 404。这时需要配置location / { root /data/www/myapp; index index.html; try_files $uri $uri/ /index.html; }try_files的意思是先找对应的文件找不到就找对应的目录再找不到就直接返回/index.html让前端路由接管处理。这个配置我认为是前端部署里价值最高的一个知识点。3.3 反向代理与负载均衡upstream 的配置逻辑反向代理是 nginx 使用最广泛的场景。配置其实很简洁server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_server; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }proxy_pass有两种写法区别很关键# 写法一不带 URI proxy_pass http://backend_server; # 写法二带 URI proxy_pass http://backend_server/;带不带末尾的/location 匹配到的路径会以不同方式拼接到后端。带上/时location 匹配的部分会被替换成/不带时原路径原样透传。比如请求/api/user/list不带/转发给后端为/api/user/list带/转发给后端为/user/list这个差异曾导致我在一个项目里排查了半个多小时后来养成了习惯每次写完proxy_pass都先确认末尾斜杠。负载均衡用upstream指令upstream backend_server { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; } server { listen 80; location / { proxy_pass http://backend_server; } }默认是加权轮询weight3的机器接收的流量是weight1的三倍。backup标记的机器是备用节点只有在其他节点都不可用时才启用。这里需要注意如果后端是 Spring Boot 之类的有状态应用Session 存本地轮询会导致 Session 丢失。有两个解决办法一是用ip_hash让同一 IP 固定访问同一台后端二是把 Session 外置到 Redis。前者配置简单后者架构更合理。还有一个容易被忽略的细节是长连接配置。默认proxy_pass到后端是短连接频繁握手很浪费性能。加上这几行upstream backend_server { server 192.168.1.10:8080; keepalive 32; } location / { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Connection ; }实测效果很明显吞吐量能提升不少尤其是后端接口响应本身就快的时候。3.4 SSL 证书与私钥类型哪些格式能直接用配置 HTTPS 时最常见的报错集中在证书文件格式和私钥类型。nginx 的ssl_certificate指令接收 PEM 格式的证书链ssl_certificate_key接收 PEM 格式的私钥。server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; }关于私钥类型这是很多人问的高频问题。nginx 支持的私钥类型主要是 RSA 和 ECCECDSA。当前主流的证书申请服务商默认给的私钥一般是 RSA但越来越多场景开始用 ECC。两者的核心区别是类型长度性能兼容性RSA2048/4096 位握手计算量大极好ECC256/384 位握手计算量小良好老客户端可能不支持现代浏览器和服务器基本都支持 ECC但如果你的用户里还有大量老旧系统保守一点选 RSA。还有一个情况是证书商给你的私钥可能是 PKCS#8 格式文件头是BEGIN PRIVATE KEY而 nginx 有些老版本对 PKCS#8 支持不好报错类似SSL_CTX_use_PrivateKey_file(...) failed (SSL: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag)解决办法是用 OpenSSL 转成传统的 PKCS#1 格式openssl rsa -in server.key -out server_rsa.key转换后文件头变成BEGIN RSA PRIVATE KEY就能被正常识别了。如果需要验证客户端证书也就是双向 TLS 的场景比如某些内部接口要求客户端带证书访问配置要加两行server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/server.pem; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_client_certificate /etc/nginx/ssl/ca.pem; ssl_verify_client on; }ssl_client_certificate指向签发客户端证书的 CA 证书ssl_verify_client on开启强制验证。开启之后客户端访问这个端口必须带证书否则握手阶段就直接失败请求根本到不了应用层。这个配置适合接口对接场景比如支付回调或者内部服务间通信。证书更新后的重载证书文件有有效期过期前需要更换。替换证书文件本身不需要重启 nginx只需要执行nginx -s reload让 worker 进程重新加载证书。在 Docker 环境下的操作方式稍微不同我在第 4 章会说。4. 实战场景从静态部署到流媒体转发4.1 前端构建产物部署pnpm run build 之后怎么启动现在前端项目基本都是构建后部署pnpm run build会在项目根目录生成dist文件夹这就是纯静态文件。部署方式就是把这个目录交给 nginx 托管。假设构建产物/data/www/myapp/distnginx 配置server { listen 80; server_name myapp.example.com; gzip on; gzip_types text/plain text/css application/json application/javascript application/xml; gzip_min_length 1k; location / { root /data/www/myapp/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend_server; proxy_set_header Host $host; } }这里有几个点值得展开。gzip开启后纯文本类资源的传输体积能缩小 60% 以上对首屏加载速度提升非常明显。gzip_min_length 1k表示小于 1KB 的文件不压缩因为压缩本身有开销小文件压缩了反而得不偿失。location /托管静态文件try_files解决 history 路由刷新 404 的问题。location /api/把接口请求反向代理到后端服务前端代码里只写相对路径/api/xxx这样前后端通过同一个域名访问不会出现跨域问题。这也是为什么很多前端项目部署时不需要后端开启 CORS 的原因——同源策略只针对不同域名的请求。新版 nginx 要注意 1.26 里的一个变化如果你用的是 nginx 1.26 及之后的版本默认gzip模块行为没有变化但proxy_pass相关的http2配置项从listen 443 ssl http2变成了独立的http2 on指令。在 1.25 之前老写法是listen 443 ssl http2;1.25 之后的写法是listen 443 ssl; http2 on;老写法在新版本上会直接报错配置检查就过不了升级版本之后要记得改。4.2 用 nginx 搭一个流媒体 RTMP 转发如果你需要在网站上做直播或者视频推流nginx 本身不带 RTMP 功能需要额外编译模块。这与nginx rtmp的搜索词直接相关。从压缩包安装的 nginx 大概率不带 RTMP 模块检查方法nginx -V 21 | grep rtmp没有输出说明没编译进去。需要自己重新编译加上nginx-rtmp-module这个第三方模块。编译步骤不复杂在 configure 时加上./configure --add-module/path/to/nginx-rtmp-moduleRTMP 配置在 nginx.conf 里是和一个http块平级的独立块不能写在http里面rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; allow publish 127.0.0.1; deny publish all; } } }这里的application live相当于一个推流通道OBS 推流地址可以写rtmp://服务器IP/live/房间号播放地址就是rtmp://服务器IP/live/房间号。record off表示不做本地录制节省磁盘。allow publish和deny publish是推流权限控制默认只允许本机推流防止别人往你的流媒体服务器上乱推。还有一点很关键RTMP 是 Adobe 的私有协议浏览器原生不支持播放。实际项目中通常是 nginx 只负责接收 RTMP 推流再用 HTTP-FLV 或者 HLS 协议把流转给播放端。可以加这部分配置application live { live on; hls on; hls_path /data/www/hls; hls_fragment 2s; }播放端改用 HTTP 访问http://服务器IP/hls/房间号.m3u8用支持 HLS 的播放器包括手机浏览器和很多 HTML5 播放器就能直接看。4.3 Docker 与 K8s 环境下的 nginx 实操容器化部署下nginx 的使用方式略有不同。官方镜像的 nginx 配置文件位置是有讲究的主配置/etc/nginx/nginx.conf子配置/etc/nginx/conf.d/*.conf主配置里最后一排是include /etc/nginx/conf.d/*.conf;所以新增站点配置最干净的做法是在conf.d下面放独立配置文件而不是改主配置。Docker 挂载多个项目目录是高频需求。比如宿主机上有两个前端项目目录分别映射到容器的不同路径再通过不同端口或者不同域名区分docker run -d \ --name nginx \ -p 80:80 \ -p 443:443 \ -v /data/www/project1:/usr/share/nginx/html/project1:ro \ -v /data/www/project2:/usr/share/nginx/html/project2:ro \ -v /data/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /data/nginx/ssl:/etc/nginx/ssl:ro \ nginx:1.26容器里的/etc/nginx/conf.d/default.conf被宿主机上的/data/nginx/conf.d整个覆盖这样配置文件可以直接在宿主机上编辑改完docker exec nginx nginx -t验证语法然后docker exec nginx nginx -s reload重载。证书更新的重载在容器里执行docker exec nginx nginx -s reload这个命令的意思是让容器内的 nginx 进程重新加载证书文件。前提是你把证书目录以卷的形式挂载进去了否则换证书文件之后容器内还是旧文件reload 也没用。K8s 集群中部署 nginx的做法通常是作为 Ingress Controller。你的服务如果是nginxmysql组成的应用栈部署思路是这样MySQL 用 StatefulSet 部署通过 Service 暴露内网地址nginx 用 Deployment 部署配置反向代理把请求转发到 MySQL Service 的地址相当于给 MySQL 加了一个访问网关nginx 的配置存放在 ConfigMap 中修改 ConfigMap 后滚动更新 Pod这是个很常见的内部系统架构nginx 做数据库访问代理可以统一做流控、日志和 IP 白名单。不过要注意nginx 默认的stream模块才能做 TCP 级别的 MySQL 转发HTTP 模块的proxy_pass只能转发 HTTP 协议。MySQL 是 TCP 协议用 HTTP 代理是转不动的。需要这样配置stream { upstream mysql_backend { server 10.0.0.5:3306; } server { listen 3306; proxy_pass mysql_backend; } }这个配置写在http块外面是events块的平级块。国内中间件场景还有一种常见搭配前面用 nginx 做入口后面挂 TongWeb 应用服务器。TongWeb 本身是 Java 应用服务器和 Tomcat 类似但很多老系统跑在它上面。搭配思路很简单nginx 的proxy_pass指到 TongWeb 的端口比如 8080静态资源直接由 nginx 返回动态请求转给 TongWeb能明显减轻 TongWeb 的负载压力。5. 常见问题与排查技巧实录5.1 启动失败从报错信息反推根因端口被占用是最常见的启动失败原因。报错[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)Linux 下排查netstat -tlnp | grep :80找到占用端口的 PID如果是你自己起的一个旧 nginx用nginx -s quit优雅结束如果是其他服务占用的权衡一下让哪个服务换端口。不要上来就kill -9尤其是线上服务正在处理的请求会全部断掉。配置文件语法错误报错会直接指出来nginx: [emerg] unknown directive proxy_passss in /etc/nginx/conf.d/test.conf:3这种问题完全靠nginx -t预防。我养成了一个习惯所有配置改动之后先nginx -t再重载两步分开做不要直接 reload。因为 reload 如果遇到配置错误旧的 worker 进程会继续跑但新的 worker 起不来整个服务处于一个很尴尬的中间状态线上环境非常危险。工作进程权限问题。如果 nginx 的 worker 进程是用nginx用户运行的而配置的日志目录或者证书文件权限不对会出现[error] open() /var/log/nginx/error.log failed (13: Permission denied)排查方法很简单ls -l看目录属主把对应目录的属主改成 nginx 用户或者调整配置里的user指令。5.2 状态码问题速查403、502、504、404HTTP 状态码能直接告诉我们问题出在哪层。我在运维过程中总结了一下常用的排错路径403 Forbidden。静态文件场景下通常是目录没权限或者没有 index 文件。排查看目录是否有r和x权限x权限对目录来说是进入的权限没有的话 nginx 无法进入目录访问文件。还有一个容易被忽略的如果root指向的路径不存在nginx 会返回 403 而不是 404这是它的一个行为特点。502 Bad Gateway。反向代理时后端服务没起来或者不通。排查思路从后往前curl http://127.0.0.1:8080/health后端不通的话先解决后端问题。后端通了 502 还出现看 nginx 的错误日志常见报错connect() failed (111: Connection refused)是端口不通connect() failed (110: Connection timed out)是网络不通或后端压满。504 Gateway Timeout。后端处理太慢超过了 nginx 的等待时间。默认超时是 60 秒可以调location / { proxy_connect_timeout 5s; proxy_send_timeout 60s; proxy_read_timeout 60s; }如果是后端有大量耗时的报表导出或者接口调用可以适当调大proxy_read_timeout但最好还是从业务层优化加大超时只是缓兵之计。404 Not Found。静态文件找不到或者后端接口路径不对。先看 nginx 的 access log 里请求的是什么路径再对照 root 配置和实际文件路径。排查的时候有个技巧在配置里临时加一行add_header X-Debug-Path $request_filename;响应头会显示 nginx 实际找的文件路径一眼就能看出 root 拼接错误。CPU 占用率 100% 的问题这是一个很大的坑。大流量场景下 worker 进程 CPU 打满常见原因有三个access_log 写入太频繁磁盘 IO 跟不上开启了太多 worker_processes 且每进程 worker_connections 过高导致进程频繁切换日志文件过大且没有做切割写入效率下降解决办法日志按天切割logrotate配置静态资源开启缓存和压缩必要时关闭 access_log 或者改成只记录错误日志。还有一个容易忽略的点如果配置的server_name做了很多正则匹配CPU 消耗也会偏高生产环境优先用精确匹配和前缀匹配。5.3 平滑切换改配置不中断服务nginx 最强大的能力之一是平滑重载。修改配置后执行nginx -s reload它的原理不是 restart而是启动新的 worker 进程等旧的 worker 处理完当前请求后再退出所以用户无感知。这也是 nginx 比很多其他 Web 服务器更适合生产环境的核心原因。后端快速切换是运维里常见的需求。比如新老版本系统切换或者发布预案需要把流量从 A 集群切到 B 集群。两个办法一个是在upstream里把 A 机器的权重改成weight0让新请求全部打到 B 机器等 A 机器上存量请求处理完再下线。这个操作的优点是实时、不停服缺点是依赖配置修改和 reload。另一个是直接改proxy_pass的目标地址把上游指向 B 集群。适合后端是整体迁移的场景改完 reload 立刻生效。这两个操作如果搭配 DNS 或者注册中心使用就能形成一个完整的高可用切换方案。但注意切换前一定先备份当前配置切换后至少观察 5 分钟确认没有大面积报错再清理旧环境。5.4 Docker 环境下的排查技巧容器里排查 nginx 问题先进入容器docker exec -it nginx bash容器里通常没有完整工具有些精简镜像连vim、curl都没有但nginx -t和nginx -s reload是通用的。如果容器里执行nginx -t报错而宿主机上配置看着没问题多半是卷挂载路径对不上检查一下容器内路径是否存在docker exec nginx ls -l /etc/nginx/conf.d/有一个坑用docker run或docker-compose挂载单个文件时如果宿主机文件不存在Docker 会自动创建一个目录而不是文件导致容器内报错。所以挂载配置文件前先确认宿主机上文件是存在的用ls -l看一下类型文件前面显示d就是目录明显不对。写在最后从拿到nginx_1.7.11.3_Gryphon.zip这个压缩包到它稳稳当当地在线上跑起来中间涉及版本识别、校验、安装、配置、排错一整套流程。我个人在实际操作中的体会是版本号帮你判断能做什么配置决定它做什么排查能力决定你能不能睡得着觉。如果你手上也是一份带代号的 nginx 构建包我建议第一件事永远是先跑nginx -V把编译参数看清楚有些模块比如stream、http_ssl_module、rtmp如果编译时没带上后面配置写得再漂亮也是白搭。最后再分享一个小技巧拿到任何新环境我都会先做一遍nginx -t然后故意写一个错误配置再跑一遍nginx -t确认报错机制正常。听起来很傻但这样做过之后后面配错什么都能第一时间反应过来。这个习惯帮我避过不少雷也分享给你。本文还有配套的精品资源点击获取