nginx学习笔记

原创已于 2025-09-22 17:14:38 修改 · 1k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#nginx #学习 #笔记

于 2025-09-22 16:17:33 首次发布

运维菜鸟学习笔记专栏收录该内容

2 篇文章

订阅专栏

前言

nginx是一个可以部署网站的服务器，可以用更少的资源处理更多用户的请求，让网站速度更快更稳定
本篇文章主要是关于nginx学习笔记和参与工作后遇到的关于nginx问题的一些记录

1. nginx学习总结

1.1 nginx安装配置

1.1.1 nginx安装环境

（1）系统环境：Linux（CentOS7）

（2）gcc：安装nginx需要先将官网下载的源码进行编译，编译依赖gcc环境，如果没有gcc环境，需要安装gcc

yum install gcc-c++

（3）PCRE：PCRE(Perl Compatible Regular Expressions)是一个Perl库，包括 perl 兼容的正则表达式库。nginx的http模块使用pcre来解析正则表达式，所以需要在linux上安装pcre库

yum install -y pcre pcre-devel

（4）zlib：zlib库提供了很多种压缩和解压缩的方式，nginx使用zlib对http包的内容进行gzip，所以需要在linux上安装zlib库

yum install -y zlib zlib-devel

（5）openssl：OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议，并提供丰富的应用程序供测试或其它目的使用。nginx不仅支持http协议，还支持https（即在ssl协议上传输http），所以需要在linux安装openssl库。

yum install -y openssl openssl-devel

1.1.2 编译安装

（1）下载源码包

wget -c https://nginx.org/download/nginx-1.12.0.tar.gz

（2）解压源码

tar -zxvf nginx-1.12.0.tar.gz

（3）配置编译参数+安装

cd nginx-1.12.0
#编译参数1：手动编译安装的+配置安装
#每行分别表示：安装目录、启用 HTTPS、启用状态监控、强制使用 PCRE、真实 IP 头处理（可选）
./configure \
--prefix=/work/nginx/nginx1-12/ \
--with-http_ssl_module \
--with-http_stub_status_module \
--with-pcre \
--with-http_realip_module
#编译参数2：
#使用 ./configure 命令时通过参数（如 --prefix、--with-http_ssl_module）指定安装路径和模块，可以避免手动修改配置或路径
./configure \
--prefix=/usr/local/nginx \
--with-http_ssl_module \
--with-http_stub_status_module \
-with-threads
#配置安装
make && sudo make install

1.1.3 nginx的启动和使用

（1）启动：进入nginx的安装目录，使用启动命令（下图表示启动成功）

cd /work/nginx/nginx1-12/ 
# 编译安装后出现的新目录
cd sbin/
# 安装目录
./nginx
# 执行启动命令
ps aux|grep nginx
# 查询nginx进程，确认Nginx 是否启动

启动成功
（2）停止

# 快速停止：此方式相当于先查出nginx进程id再使用kill命令强制杀掉进程。
./nginx -s stop
# 完整停止：此方式停止步骤是待nginx进程处理任务完毕进行停止
./nginx -s quit

（3）重启nginx

# 先停止再启动（建议）：对nginx进行重启相当于先停止nginx再启动nginx
./nginx -s quit./nginx
# 重新加载配置文件
# 当nginx的配置文件nginx.conf修改后，要想让配置生效需要重启nginx
# 使用-s reload不用先停止nginx再启动nginx即可将配置信息在nginx中生效
./nginx -s reload
# 重新打开日志文件
./nginx -s reopen

（4）测试

# 测试本地访问：在虚拟机内部运行
curl -I http://localhost
# 虚拟机内部用浏览器访问（火狐浏览器）
# 访问网址：http://localhost或http://127.0.0.1
# 外部主机访问nginx（需要临时关闭防火墙）
sudo systemctl stop firewalld

寻找对应IP地址
寻找IP地址后，可以在外部主机上进行访问
外部主机访问成功

1.1.4 nginx静态网站配置

# 查看nginx的安装目录，编译参数，配置文件和日志文件的位置等各种信息
nginx -V
#conf（配置文件）的位置
/work/nginx/nginx1-12/conf/nginx.conf

配置文件

根据配置文件中的内容，找到html文件，文件位置：/work/nginx/nginx1-12/html/index.html，可以用vim修改html文件内容（出现乱码大概是因为汉字的编码优点问题）

重新编译过的界面，就是中文的编码没改

1.1.5 nginx.conf配置文件

# work进程的数量（可修改），一个master可以有多个work
# work进程的数量保持同服务器CPU内核的数量相同是比较合适的
worker_processes auto;
# 自动设置work进程的数量
nginx -t
# 检查配置文件内容是否正确
nginx -s reload
# nginx配置文件修改后需要重新加载一下

配置文件内容

一个http块可以有过个server块，include servers/*表示把servers目录下的所有妹纸文件都包含进来，这样就可以把每个虚拟主机的配置都放在一个单独的文件里面，让主配置文件看起来更加简洁。

1.2 nginx相关功能

1.2.1 正向代理

正向代理例子：用代理服务器作为客户端，代理访问网站，把访问的结果返回给用户（代理客户端，客户端知道过程，对于服务端是透明的）

server {
	listen 8888;  # 代理服务器的端口
	resolver 8.8.8.8;  # 指定 DNS 服务器（用来解析目标域名）
	location / {
		proxy_pass http://$http_host$uri$is_args$args;  # 代理所有请求
		proxy_set_header Host $http_host;  # 告诉目标网站原始请求的域名
	}
}

1.2.2 反向代理

反向代理例子：代理服务端，对客户端是透明的，隐藏了真实的服务器IP地址、端口等信息（表后端服务器接收客户端请求，并将请求转发给合适的后端服务器处理，最后将响应返回给客户端）

# 将所有请求转发到单个后端服务器（无负载均衡）
server {
    listen 80;
    server_name example.com; #域名绑定
    location / {
        proxy_pass http://backend_server;  # 转发到单个后端，这是个变量名，实际运用的时候写IP
        proxy_set_header Host $host;
    }
}

1.2.3 负载均衡

负载均衡是一种通过 Nginx 服务器将客户端请求智能分发到多个后端服务器的技术（是反向代理的一种高级功能）
负载均衡的方法：
（1）轮询：默认方法，按顺序依次分配请求到每台服务器，当服务器性能不均时，可以用weight调整权重次数，次数越大，接收到的请求也就会越多（加权轮询）
（2）ip_hash：会根据客户端的ip地址进行一个哈希，同一个客户端的请求就会被分配到同一个服务器上（这样就可以解决一些session相关的问题，适用于需要会话保持的场景）
以下代码是一个基本的负载均衡（nginx.conf中的内容）

http {
    # upsteam定义服务器组，可以定义多个服务器（server），upstream后面的名字可以随便定
    upstream backend_servers {
        server 192.168.1.100:8080;  # 后端服务器1
        server 192.168.1.101:8080;  # 后端服务器2
        server 192.168.1.102:8080 backup;  # 备用服务器（主服务器全挂时启用）
    }
    # 默认轮询，如果需要加权重需要在选中的服务器后面添加weight属性来调整权重，比如weight=3
    server {
        listen 80;
        location / { #/表示根路径，该语句表示匹配所有访问路径
        proxy_pass http://backend_servers;  # 将请求转发到上游服务器组，得和upstream后面的名字一致
        proxy_set_header Host $host; # 在转发请求时，保留原始的域名
        proxy_set_header X-Real-IP $remote_addr; # 在转发请求时，带上用户的真实 IP
        }
    }
}

1.2.4 探测配置

探测的作用：每隔几秒“戳一下”后端服务器，看看它是否还活着（定期检查），如果发现后端服务器不行了，就暂时不使用它，等它fuh了再恢复（自动剔除）
在 Nginx 里，这种“戳一下”的行为就叫 “健康探测”（Health Check），主要用于负载均衡场景（比如把请求分发给多个后端服务器时，确保只发给健康的服务器）
放在 nginx.conf 的 http 或 upstream 块中

http {
    upstream backend {
        # 定义后端服务器列表
        server 192.168.1.100:80;
        server 192.168.1.101:80;
        # 探测配置开始
        # 1. 启用健康探测
        health_check interval=5 fails=3 passes=2;
        # 每 5 秒探测一次,如果连续 3 次探测失败，就认为服务器“死了”
        # 如果“死了”的服务器连续 2 次探测成功，就认为它“复活”了
        # 2. 定义探测的路径和超时时间（可选）
        health_check_timeout 3s; # 等待响应的超时时间（3秒）,如果3秒内没响应，就认为探测失败
        health_check_type tcp;  # 探测方式：TCP连接（或 http）
        # TCP 探测（简单粗暴），直接检查端口是否能连通（比如80端口）
        # HTTP 探测（更精准）
        # health_check_type http;  # 发送HTTP请求检查
        health_check_uri /health;     # 如果用HTTP探测，检查这个路径
        # 探测路径需要自己写（比如后端服务提供的/health接口）
        health_check_status 200;      # 只有返回200才认为健康
    }
    server {
        listen 80;
        location / {
        # 把所有请求转发给后端集群
        proxy_pass http://backend;
        }
    }
}

1.3 nginx漏洞

1.3.1 $uri导致的crlf注入漏洞

（1）产生原因：Nginx默认会对$uri进行解码，比如把%0d%0a解码成真实的回车换行（\r\n），如果攻击者在URL里插入%0d%0a，解码后就会变成回车换行，这相当于在HTTP响应头里“强行换行”，从而插入恶意内容
本质：Nginx对用户输入的URL路径解码后，未过滤特殊字符，导致攻击者能“换行”插入恶意头部或脚本
（2）举例：
理论上，只要是可以设置HTTP头的场景都会出现这个问题
场景1：冒充登录网站

location / {
    return 302 https://$host$uri;  
    # 用户访问http://example.com/test时，会跳转到https://example.com/test
}

# 攻击者URL：http://example.com/%0d%0aSet-Cookie:%20sessionid=hacked
# Nginx解码%0d%0a为回车换行，响应包变成:
HTTP/1.1 302 Moved Temporarily
Location: https://example.com/
Set-Cookie: sessionid=hacked  <-- 攻击者插入的恶意Cookie！
# 浏览器收到响应后，会乖乖设置sessionid=hacked，攻击者就能冒充登录网站了

场景2：XSS（跨站脚本攻击，Cross-Site Scripting）

# 攻击URL: http://example.com/%0d%0a%0d%0a<script>alert('被黑了')</script>
# 这里是被插入了两个回车换行（%0d%0a%0d%0a）
HTTP/1.1 302 Moved Temporarily
Location: https://example.com/

<script>alert('被黑了')</script>  <-- 浏览器会执行这段脚本！
# 虽然浏览器通常会忽略302跳转时的响应体，但某些情况下（如配合其他漏洞）仍可能触发XSS。

（3）修改方案：采用变量$request_uri
$request_uri不会解码URL编码，使用起来会安全很多

location / {
    return 302 https://$host$request_uri;  # 安全！
}

修复核心：用不解码的变量，或严格过滤用户输入
（4）检测方法：采用工具

# 如果响应头里出现了Set-Cookie: test=1，说明存在漏洞。
curl -I "http://your-server/%0d%0aSet-Cookie:test=1"

# 检查所有return、add_header等指令，确保不会拼接用户可控的变量到头部

1.3.2 目录穿越漏洞

（1）产生原因：这个常见于Nginx做反向代理的情况，这个漏洞就像是你发现小区围墙有个洞，钻过去后，通过“翻墙（特殊字符）+跳院子（不按正常路线走）”的方式，直接闯进别人家的文件柜偷东西（跳过目录限制，访问本不该被看到的文件）
（2）举例：
场景：用户在网站访问图片

# 网站通常会让用户通过URL访问文件
https://example.com/download?file=report.pdf
# 用户把file参数改成../../etc/passwd（Linux系统的用户密码文件），而服务器没有检查路径是否合法
https://example.com/download?file=../../etc/passwd

# 服务器解析路径:
# 原始路径：/var/www/html/files/../../etc/passwd
# ../表示“返回上一级目录”，所以实际路径变成：/var/www/html/etc/passwd → 再跳一级变成/var/www/etc/passwd → 最终可能跳到根目录/etc/passwd
# 服务器返回/etc/passwd的内容（包含所有用户信息），攻击者就偷到了敏感数据。

（3）造成的结果：

a. 偷看敏感文件：
Linux：/etc/passwd（用户列表）、/etc/shadow（密码哈希）、/var/log/auth.log（登录记录）
Windows：C:\Windows\System32\config\SAM（存储用户密码）
网站配置：/app/config/database.yml（数据库账号密码）
b. 上传恶意文件：
如果网站允许用户上传文件（比如头像），攻击者可能通过目录穿越把文件上传到系统目录（如/tmp/），然后执行恶意脚本
c. 控制整个服务器：
结合其他漏洞（如文件包含漏洞），攻击者甚至能植入后门，完全控制网站

（4）修改方案：
核心原则：永远不要直接信任用户输入的路径，必须严格检查和限制

a. 禁止使用…/和…\

b. 使用“白名单”限制文件类型(只允许访问特定后缀的文件（如.pdf、.jpg）)

c. 固定文件目录，用ID代替路径(不直接暴露文件路径，改用数据库ID)

d. 设置文件系统权限(确保Web服务器用户（如www-data）只能访问必要的目录，禁止读取系统文件)

e. 使用框架的安全功能(现代框架（如Spring、Django、Express）通常内置了路径检查，优先使用它们的文件下载功能，而不是自己拼接路径)

（5）检测方法：
a. 用curl或浏览器直接测试，如果返回文件内容（而不是”403禁止访问“），说明存在漏洞
b. 编码绕过（比如…/–>%2e%2e%2f）

1.3.3 HTTP header覆盖漏洞

（1）产生原因：击者通过伪造或篡改Header，覆盖服务器原本设置的合法Header，导致服务器误判或执行非法操作

Header请求头标签：

User-Agent：是谁
Host：要访问什么资源
Content-Type：什么数据类型
Authorization：是否有特殊权限

（2）举例：
场景1：服务器“信任”用户输入的Header

# 有些服务器会直接使用用户提供的Header，而不做校验
GET / HTTP/1.1
Host: evil.com  # 攻击者伪造的Host
X-Forwarded-For: 1.2.3.4  # 伪造客户端IP

# 服务器错误处理：
# 如果服务器用Host: evil.com去查询DNS或路由请求，可能跳转到恶意域名。
# 如果服务器用X-Forwarded-For: 1.2.3.4记录日志，会掩盖真实攻击者IP。

场景2：中间件/代理配置错误
比如Nginx反向代理配置不当，允许用户覆盖后端服务的Header

# 错误配置：未过滤用户输入的X-Real-IP
location / {
    proxy_set_header X-Real-IP $http_x_real_ip;  
    # 攻击者可伪造X-Real-IP
    proxy_pass http://backend;
}

# 攻击者发送
GET / HTTP/1.1
X-Real-IP: 127.0.0.1  # 覆盖真实IP
# 后端服务会认为请求来自127.0.0.1（本地），可能绕过IP限制

场景3：浏览器自动添加敏感Header
某些浏览器或扩展会自动添加Header（如Referer、Origin），如果服务器未严格校验，可能被覆盖

# 正常请求
GET /admin HTTP/1.1
Referer: https://example.com/login  # 合法来源

# 攻击者用JavaScript覆盖
fetch('/admin', {
  headers: { 'Referer': 'https://example.com/admin' }  // 伪造来源
});
# 如果服务器仅检查Referer是否为example.com，可能误判为合法请求

（3）造成的结果：

a. 伪造身份：
覆盖Cookie劫持用户会话
覆盖Authorization伪造API令牌
b. 绕过安全限制：
覆盖Content-Security-Policy加载恶意脚本
覆盖X-Frame-Options触发点击劫持
c. 访问内部服务：
覆盖Host跳转到内网IP（如Host: 192.168.1.1）
覆盖X-Forwarded-Host访问未公开的后端服务
d. 篡改业务逻辑：
覆盖X-Price: 1000为X-Price: 1，低价购买商品
覆盖User-Agent伪装成爬虫绕过限制

（4）修改方案：
核心原则：永远不要信任用户输入的Header，必须严格校验和过滤

a. 校验Header值：对关键Header（如Host、X-Forwarded-For）做白名单校验

b. 禁止用户覆盖敏感Header：在代理层（如Nginx）过滤危险Header

c. 使用安全框架：现代框架（如Spring Security、Django）默认会校验Header，优先使用它们的安全功能

d. 设置HTTP安全头：防止点击劫持（X-Frame-Options: DENY），防止XXS（Content-Security-Policy: default-src ‘self’）

e. 记录和监控：记录异常Header请求（如频繁修改Host的IP），及时告警

（5）检测方法
a. 手动测试：用curl或浏览器开发者工具构造请求，尝试覆盖常见的Header，观察服务器是否返回异常响应（如跳转到evil.com或记录错误IP）

# 测试覆盖Host
curl -H "Host: evil.com" https://example.com

# 测试覆盖X-Forwarded-For
curl -H "X-Forwarded-For: 127.0.0.1" https://example.com

b. 使用工具扫描

Burp Suite：拦截请求，修改Header并重放
OWASP ZAP：自动检测Header注入漏洞
Postman：手动构造请求测试Header覆盖

c. 代码审计：检测服务器代码是否直接使用用户输入的Header

1.3.4 文件名逻辑漏洞

（1）产生原因：（以Nginx的CVE-2013-4547为例）某些旧版Nginx（如1.4.x及之前版本）在处理文件名时，会被“空格”和“截断符”（\0，也就是键盘上的0键按住Shift）搞混，导致它错误地认为文件是其他类型，从而绕过安全限制
（2）举例：
正常情况：上传一个文件test.jpg，访问test.jpg，Nginx会直接显示图片，因为它不是.php文件
漏洞利用：上传一个文件，但文件名末尾偷偷加个空格（比如test.jpg ，注意空格在最后），然后访问test.jpg[空格]\0.php（\0是截断符，实际攻击中不需要手动输入，用工具构造即可）
Nginx的迷惑行为：它看到.php结尾，先把请求交给PHP解释器，但PHP解释器读到\0时，会认为文件名到此结束，于是把test.jpg[空格]当成PHP文件执行。
结果：一张图片被当成了代码运行
（3）结果：

攻击者步骤：
上传一个恶意图片（如hacker.jpg），内容其实是PHP代码（比如<?php system('whoami'); ?>）
通过构造特殊URL（如hacker.jpg[空格]\0.php），让Nginx把图片当成PHP执行
服务器返回执行结果（如当前用户权限），攻击者可能进一步控制服务器
实际影响：
即使网站限制了.php上传，攻击者仍可通过图片+漏洞绕过限制
可能泄露服务器敏感信息，甚至植入后门

（4）修改方案：

a. 升级nginx
b. 过滤特殊字符（在文件上传时，禁止文件名包含空格和\0等字符）
c. 文件重命名（上传文件时，服务器自动生成随机文件名（如abc123.jpg），避免使用用户提供的原始文件名）

1.3.5 nginx越界读取缓存漏洞

（1）产生原因：（以Nginx的CVE-2017-7529为例）某些旧版Nginx（如1.13.2及之前版本）在处理“页码请求”时，会被负数和超大数绕晕，导致翻到错误的页码，甚至把敏感信息也递出去
（2）举例：
HTTP的Range头：
用户可以通过Range: bytes=X-Y请求文件的某一部分（比如跳过前500字节，只下载501-1000字节），这常用于断点续传或节省流
Nginx的“翻车”操作：
漏洞版本中，Nginx在处理Range头时，未严格检查数字是否合法，攻击者可以构造恶意请求，比如Range: bytes=-600,-9223372036854774591（两个负数），或Range: bytes=1000-9999999999999999999（超大数）
Nginx会被这些数字绕晕，计算出一个负数的起始位置，导致从文件开头往前翻页（比如从第-100页开始读）
如果翻到的位置是缓存文件的“封面”（如后端服务器IP、加密密钥等敏感信息），就会被泄露
缓存文件的“夹心结构”：
Nginx反向代理时，会缓存静态文件（如图片、CSS），每个缓存文件像“三明治”：
封面：文件头（包含Nginx版本、后端服务器IP等）
夹心：HTTP返回包头（如响应头）
面包：HTTP返回包体（用户实际请求的文件内容）
漏洞发生时，Nginx会从“夹心”或“封面”部分读取数据，泄露敏感信息
（3）结果：

影响范围：Nginx 0.5.6 - 1.13.2版本（默认配置下，开启缓存时）
信息泄露：攻击者可获取后端服务器IP、内部网络结构、加密密钥等，为进一步攻击铺路
低门槛攻击：只需发送一个恶意HTTP请求，无需复杂操作

（4）修改方案：

a. 升级nginx
b. 关闭代理缓存
c. 限制Range头范围（通过代码或防火墙规则，过滤非法Range请求（如负数、超大数））

2. nginx实操总结

2.1 nginx升级（用包升级）

（1）进行进程查询，能够看到主机有nginx进行在运行

ps -ef|grep nginx

（2）将文件通过文件管理放进nginx文件夹中，随后进行解压

cd $HOME/nginx/package
tar -zxf nginx-1.26.3.tar.gz
tar -zxf openssl-1.1.1g.tar.gz
tar -zxf pcre-8.43.tar.gz
tar -zxf zlib-1.2.11.tar.gz
tar -zxf headers-more-nginx-module-0.34.tar.gz
tar -zxf nginx-module-vts-0.2.1.tar.gz

（3）解压后进入nginx-1.26.3文件夹，开始进行编译参数，文件目录是$HOME/nginx/1263

cd nginx-1.26.3
./configure --prefix=$HOME/nginx/1263 \
 --add-module=$HOME/nginx/package/headers-more-nginx-module-0.34 \
 --add-module=$HOME/nginx/package/nginx-module-vts-0.2.1 \
 --with-pcre=$HOME/nginx/package/pcre-8.43 \
 --with-openssl=$HOME/nginx/package/openssl-1.1.1g \
 --with-zlib=$HOME/nginx/package/zlib-1.2.11 \
 --with-http_sub_module \
 --with-http_stub_status_module \
 --with-http_realip_module \
 --with-ld-opt="-L/usr/local/lib -Wl,-u,pcre_version" \
 --with-cc-opt=-O2 \
 --with-pcre-jit \
 --with-http_v2_module \
 --without-mail_pop3_module \
 --without-mail_imap_module \
 --without-mail_smtp_module \
 --with-http_addition_module \
 --with-http_auth_request_module \
 --with-http_secure_link_module \
 --with-http_random_index_module \
 --with-http_gzip_static_module \
 --with-http_dav_module \
 --with-http_flv_module \
 --with-http_mp4_module \
 --with-http_gunzip_module \
 --with-threads \
 --with-stream \
 --with-stream_ssl_module \
 --with-stream_ssl_preread_module \
 --with-http_ssl_module

（4）编译参数完成后，下一步便是进行编译和安装

# 编译安装
make && make install
# 设置环境变量"
mkdir $HOME/bin
ln -sf $HOME/nginx/1263/sbin/nginx $HOME/bin/nginx

（5）安装完后查看nginx版本，看到还是之前的，这是因为环境变量还没有设置，需要重新设置一下环境变量（没有bin目录需要在HOME下创建一个bin目录，mkdir $HOME/bin），重新设置环境变量后再查看nginx版本后就显示的是已经更新了的版本

# 查看版本
nginx -v

（7）版本已经更新，查看进程，可以先检查一下配置文件，查看配置文件没有问题后，停止旧的nginx进程，启动新的nginx进程，如果nginx配置文件更新了，可以重新进行加载一下，然后就能发现两次的PID不一样，说明现在用的是更新后的nginx的配置了

nginx -tc /emall/openresty/12201/nginx/conf/nginx.conf
# 检测nginx配置是否正确
nginx -c /emall/openresty/12201/nginx/conf/nginx.conf
# 执行nginx进程
nginx -c /emall/openresty/12201/nginx/conf/nginx.conf -s reload
# 重新加载nginx配置

（8）确认nginx更新完成，可以把package里面的解压文件给删除了

rm -rf $HOME/nginx/package/nginx-1.26.3
rm -rf $HOME/nginx/package/openssl-1.1.1g
rm -rf $HOME/nginx/package/pcre-8.43
rm -rf $HOME/nginx/package/zlib-1.2.11
rm -rf $HOME/nginx/package/headers-more-nginx-module-0.34
rm -rf $HOME/nginx/package/nginx-module-vts-0.2.1

（9）问题记录：编译参数报错./configure: error:invalid optior “ ”
排查原因，是因为./configure语句格式有问题，发现是换行符\后面存在空格，将空格剔除重新执行后，可以正常运行

2.2 nobody用户启动nginx问题

nobody用户
在root用户下启动nginx，发现子进程的用户是nobody，nobody是被降权的非特权用户，可能会出现权限方面的问题，随后去日志进行查看，发现果然出现了相关报错信息
权限报错
报错信息显示没有权限访问access_log（这个是手动创建的文件），核实文件权限是在root用户下的，最开始尝试用sudo来让root用户启动nginx，但启动后仍然显示的是nobody，于是后面选择把文件赋予e3base用户的相关权限后，用e3base用户启动nginx
修改文件权限
用e3base用户启动nginx后，进程前面显示的用户均为e3base，核实日志也没有出现报错信息，主机对应的系统功能正常

sudo -u e3base /e3base/applicationpaas/nginx/sbin/nginx

用e3base启动nginx
在access_log目录下面也能看到新生成的日志文件
在这里插入图片描述
【PS.为避免出现用root用户启动但是子进程的用户是nobody的情况，在对nginx进行升级的时候，可以先看一下之前的nginx进程是哪个用户启动的，然后将主机切换到对应用户后再进行安装部署启动，注意文件的权限要是该用户下的哦】

2.3 nginx证书到期后替换

（1）如果新的证书压缩包中的文件名字和主机上的证书名字不一样，需要将新的证书压缩包中的名字重命名成主机上证书的名字
（2）通过nginx进程找到nginx/conf的对应地址，查看conf下的证书有哪些，将证书备份后用新的证书替换掉

cd /root/opt/nginx/conf
# 备份
mv hczq.com.crt hczq.com.crt.20250909
mv hczq.com.key hczq.com.key.20250909
# 然后将新的证书复制到该目录下

（3）检测配置文件是否匹配，检测成功后，平滑重启nginx

/root/opt/nginx/sbin/nginx -c /root/opt/nginx/conf/nginx.conf -s reload
# 平滑重启

2.4 目标使用过期的TLS1.0 版协议漏洞处理

（1）首先需要确认，主机有nginx进程，且nginx.conf文件中使用了ssl参数，以上条件满足，则可采用下述方法对漏洞进行处理
（2）查看nginx进程，确认nginx配置文件nginx.conf位置
（3）备份旧的nginx.conf文件为nginx.conf.bak（便于回退）

# 可以给备份文件加上时间戳，比如nginx.conf.bak20250922
cp nginx.conf nginx.conf.bak

（3）进入nginx.conf文件，修改ssl_protocols参数

vim nginx.conf
# 修改参数
ssl_protocols TLSv1.2 TLSv1.3;
# 禁用 TLS 1.0，仅允许 TLS 1.2 和 TLS 1.3

（4）检查配置，确保配置文件匹配，检查配置成功，平滑重启nginx

/root/opt/nginx/sbin/nginx -tc /root/opt/nginx/conf/nginx.conf
/root/opt/nginx/sbin/nginx -c /root/opt/nginx/conf/nginx.conf -s reload

3. 用openresty对nginx进行升级

（1）用openresty对nginx升级时因为主机上nginx相关组件版本太老，和nginx-1.26.3版本存在环境不兼容的问题，所以会采用openresty对nginx进行升级
（2）因为需要升级的主机上存在一个fastdfs环境，但是主机上原有的这个环境太老了，和openresty-1.27.1.1版本存在不兼容问题，所以在安装openresty之前，需要安装fastdfs环境
（3）fastdfs直接安装会安装到/usr/lib64下面，如果害怕覆盖原有路径，可以采用独立目录安装的方式，但此方式在环境比较简单的主机上能成功，主机环境比较复杂的我安装失败了，此方法仅供参考

3.1 安装fastdfs

3.1.1 直接安装

（1）在package目录下解压libfastcommon-1.0.75、libserverframe-1.2.5、fastdfs-6.12.2源码包
（2）安装 libfastcommon-1.0.75

cd libfastcommon-1.0.75
./make
./make install

（3）安装 libserverframe-1.2.5

cd libserverframe-1.2.5
./make
./make install

(4)安装 FastDFS-6.12.2

cd FastDFS-6.12.2
./make
./make install

(5)配置 FastDFS 服务

因为目前是旧的FastDFS 服务在运行，可以暂时只使用旧的FastDFS 服务，不开启新的FastDFS 服务相关内容
可以将新的配置文件模板备份，然后将旧fastdfs的配置文件复制到/fastdfs/etc/下面

3.1.2 安装到独立目录下

（1）前期准备工作

# 创建openresty、fastdfs（独立安装fastdfs）、fastdfs/package（目录用于存放fastdfs安装相关的包）目录
mkdir -p /root/opt/openresty/fastdfs/package
# 将openresty安装所需要的install和package目录复制到openresty目录下
# 将fastdfs安装所欲要的包复制到fastdfs/package目录下
# 创建fastdfs下lib、bin、conf、include目录用于存放静态库、动态库、头文件等
mkdir -p /root/opt/openresty/fastdfs/{lib,bin,conf,include}
# fastcommon,fastdfs,sf目录分别存放libfastcommon、libserverframe、fastdfs-6.12.2编译后的.h文件
mkdir -p /root/opt/openresty/fastdfs/include/{fastcommon,sf,fastdfs}

（2）独立目录安装fastdfs
首先，进入fastdfs/package目录，解压压缩包

tar -zxf libfastcommon-1.0.75.tar.gz
tar -zxf libserverframe-1.2.5.tar.gz
tar -zxf fastdfs-6.12.2.tar.gz

（3）libfastcommon手动复制安装

cd libfastcommon-1.0.75
./make.sh
cp -r src/*.so* /root/opt/openresty/fastdfs/lib/
cp -r src/*.a /root/opt/openresty/fastdfs/lib/
cp -r src/*.h /root/opt/openresty/fastdfs/include/fastcommon/

（4）libserverframe手动复制安装
libserverframe和libfastcommon存在依赖关系，所以需要临时设置环境变量，不然编译的时候会报错

cd libserverframe-1.2.5
# 设置临时环境变量（在安装过程中，如果有依赖找不到，那就再重新执行一遍）
export C_INCLUDE_PATH=/root/opt/openresty/fastdfs/include/:$C_INCLUDE_PATH
export LIBRARY_PATH=/root/opt/openresty/fastdfs/lib/:$LIBRARY_PATH
export LD_LIBRARY_PATH=/root/opt/openresty/fastdfs/lib:$LD_LIBRARY_PATH
export CFLAGS="-I/root/opt/openresty/fastdfs/include"

./make.sh

cp src/*.so* /root/opt/openresty/fastdfs/lib/  # 复制动态库（包括符号链接）
cp src/*.a /root/opt/openresty/fastdfs/lib/    # 复制静态库（可能没有）
cp src/*.h /root/opt/openresty/fastdfs/include/sf/      # 复制头文件

（5）fastdfs-6.12.2手动复制安装

cd fastdfs-6.12.2
./make.sh
cp client/fdfs_* /root/opt/openresty/fastdfs/bin/
cp storage/fdfs_storaged /root/opt/openresty/fastdfs/bin/
cp tracker/fdfs_trackerd /root/opt/openresty/fastdfs/bin/

cp conf/* /root/opt/openresty/fastdfs/conf/

cp common/*.h /root/opt/openresty/fastdfs/include/fastdfs/
cp client/*.h /root/opt/openresty/fastdfs/include/fastdfs/
cp storage/*.h /root/opt/openresty/fastdfs/include/fastdfs/
cp tracker/*.h /root/opt/openresty/fastdfs/include/fastdfs/
cp storage/trunk_mgr/*.h* /root/opt/openresty/fastdfs/include/fastdfs/

cp client/libfdfsclient.a /root/opt/openresty/fastdfs/lib/
cp client/libfdfsclient.so /root/opt/openresty/fastdfs/lib/

（6）fastdfs-nginx-module修改配置参数

tar -zxf fastdfs-nginx-module-1.24.tar.gz
cd fastdfs-nginx-module-1.24/src
cp mod_fastdfs.conf /root/opt/openresty/fastdfs/conf

# 进入config文件修改对应参数
vim config
# 修改incs的参数
/root/opt/openresty/fastdfs/include/fastdfs /root/opt/openresty/fastdfs/include/fastcommon
# 修改DFDFS_MOD_CONF_FILENAME的参数
/root/opt/openresty/fastdfs/conf/mod_fastdfs.conf\

3.2 安装openresty1.27.1.1

fastdfs-nginx-module的配置参数需要修改到对应路径后再对openresty进行编译安装
（1）编辑install中的openresty.sh文件

# 在configure下面添加
--add-module=$HOME/openresty/package/fastdfs-nginx-module/src \
# 在configure中修改
--with-ld-opt="-L/usr/local/lib -Wl,-u,pcre_version -L$HOME/openresty/fastdfs/lib"

# 解释
--with-ld-opt="-L/usr/local/lib -Wl,-u,pcre_version" # 原来的
--with-ld-opt="-L$HOME/openresty/fastdfs/lib" # 新增的

（2）运行脚本进行安装

sh openresty.sh

4、检查配置，确保配置文件匹配

nginx -tc /root/opt/nginx/conf/nginx.conf

5、平滑重启nginx

nginx -c /root/opt/nginx/conf/nginx.conf -s reload

总结

以上是nginx学习以及实践遇到的问题以及对应解决办法的全部内容，后续如果在nginx遇到其他问题，会继续进行更新