nginx

发布于:2025-07-10 ⋅ 阅读:(12) ⋅ 点赞:(0)

nginx安装

1.解压nginx.tar.gz包
tar -zxvf nginx.tar.gz
2.编译安装

  • ./configure --prefix=/usr/local/nginx
  • make
  • make install
    其中/usr/local/nginx代表nginx安装路径
    错误提示:


如果提示
checking for OS
+ Linux 3.10.0-693.el7.x86_64 x86_64
checking for C compiler ... not found
./configure: error: C compiler cc is not found

解决办法:yum install -y gcc
------------------------------------
如果提示
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.

解决办法:安装perl库
yum install -y pcre pcre-devel
------------------------------------
如果提示
./configure: error: the HTTP gzip module requires the zlib library.
You can either disable the module by using --without-http_gzip_module
option, or install the zlib library into the system, or build the zlib library
statically from the source with nginx by using --with-zlib=<path> option.

解决办法:安装zlib库
yum install -y zlib zlib-devel

3.启动
进入安装好的目录:/usr/local/nginx/sbin

  • ./nginx启动
  • ./nginx -s stop快速停止
  • ./nginx -s quit优雅关闭
  • ./nginx -s reload重新加载配置文件

4.防火墙

  • 关闭防火墙:systemctl stop firewalld.service
  • 禁止防火墙开机启动:systemctl disable firewalld.service
  • 放行端口:firewall-cmd --zone=public --add-port=80/tcp --permanent
  • 重启防火墙:firewall-cmd --reload

5.将nginx安装成系统服务
创建服务脚本
vi /usr/lib/systemd/system/nginx.service
脚本内容:

[Unit]
Description=nginx - web server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
ExecQuit=/usr/local/nginx/sbin/nginx -s quit
PrivateTmp=true


[Install]
wantedBy=multi-user.target

重新加载系统服务
systemctl daemon-reload

启动服务
systemctl start nginx.service

开机启动
systemctl enable nginx.service

nginx基础使用

目录结构

进入Nginx的主目录我们可以看到这些文件夹
client_body_temp conf fastcgi_temp html logs proxy_temp sbin scgi_temp uwsgi_temp
其中这几个文件夹在刚安装好后是没有的,主要是用来存放运行过程中的临时文件
client_body_temp fastcgi_temp proxy_temp scgi_temp

conf

用来存放配置文件相关内容

html

用来存放静态文件的默认目录html 、css等

sbin

nginx的主程序

nginx配置与应用场景

worker_processes

worker_processes 1;默认为1,表示开启一个业务进程

worker_connections

worker_connections 1024;单个业务进程可接受连接数

include mime.types

include mime.types;引入http mime类型

default_type application/octet-stream

default_type application/octet-stream;如果mime类型没有匹配上,默认使用二进制的方式传输。

sendfile on

sendfile on;使用linux的sendfile(socket,file,len)高效网络传输,也就是0拷贝。
未开启:
在这里插入图片描述

开启后:
在这里插入图片描述

keepalive_timeout 65;

keepalive_timeout 65;表示客户端与服务器直接的HTTP链接处于空闲状态时,最多保持65秒不关闭连接。
如果65秒内客户端没有再次发起请求,nginx就会主动断开这个连接。

server

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;
    }
}

servername匹配规则: 我们需要注意的是servername匹配分先后顺序,写在前面的匹配上就不会继续往下匹配了
完整匹配:我们可以在同一servername中匹配多个域名
server_name vod.mmban.com www1.mmban.com;
通配符匹配
server_name *.mmban.com
通配符结束匹配
server_name vod.*;
正则匹配
server_name ~^[0-9]+\.mmban\.com$;

反向代理

反向代理理解
在这里插入图片描述

反向代理

location / {
            proxy_pass http://atguigu.com/;
        }

基于反向代理的负载均衡

upstream httpd {
    server 192.168.44.102:80;
    server 192.168.43.103:80;
}

完整配置

http {
    # 定义负载均衡池
    upstream httpd {
        server 192.168.44.102:80;
        server 192.168.43.103:80;
    }

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            proxy_pass http://httpd;
        }
    }
}

负载均衡默认使用轮询(round-robin)

但是也可以通过参数来配置策略

upstream httpd {
    server 192.168.44.102 weight=3;
    server 192.168.43.103 weight=1;
}

weight权重

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。

upstream httpd {
    server 127.0.0.1:8050 weight=10 down;
    server 127.0.0.1:8060 weight=1;
    server 127.0.0.1:8060 weight=1 backup;
}
  • down:表示当前的server暂时不参与负载
  • weight:默认为1.weight越大,负载的权重就越大。
  • backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。

ip_hash

ip_hash是nginx负载均衡中的一种策略,作用是:让来自同一个客户端ip的请求始终转发到同一台后端服务器上(只要后端服务器列表没变)
默认情况下nginx使用轮询来分发请求,导致:

  • 同一个用户访问一次是服务器A
  • 第二次是服务器B
    这对于需要会话保持(如登录状态、购物车)的业务是有问题的。
    所以我们使用ip_hash,保持用户使用访问同一台服务器。

配置方式:

http {
    upstream httpd {
        ip_hash;  # 开启 ip_hash 负载均衡策略

        server 192.168.44.102:80;
        server 192.168.43.103:80;
    }

    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://httpd;
        }
    }
}

⚠️限制:

  • ip_hash不能和权重一起使用
  • 如果后端服务器有变(添加/删除),哈希分配会全部变化,不能保持用户分布一致
  • 如果客户端是通过网关NAT出来的,多个用户ip会一样,负载不均

least_conn

最少连接访问
将请求转发给当前连接数最少的后端服务器
假设你有两个后端服务器:
服务地址当前连接数192.168.1.101:802192.168.1.102:8010

那么下一个请求就会被分发给 连接数更少的 192.168.1.101:80。
在配置中应该这么写

http {
    upstream backend {
        least_conn;  # 开启 least_conn 策略

        server 192.168.1.101:80;
        server 192.168.1.102:80;
    }

    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://backend;
        }
    }
}

⚠️ 使用限制

  • least_conn 要在 Nginx 1.3.1+ 或 1.2.2+ 版本后才支持;
  • 某些老版本编译时未开启此模块,使用会报错;
  • 不支持 ip_hash 同时使用;

url_hash

根据用户访问的url定向转发请求
url_hash 是一种更细粒度的请求分发策略,用于实现“相同 URL 总是转发给同一个后端服务器”的功能,常用于缓存、CDN、或资源固定定位的场景
url_hash 是一种基于请求 URL 计算哈希值的 Nginx 负载均衡策略,相同的 URL 会始终被分配到同一台后端服务器。

📌 举个例子:
你访问的两个 URL 分别是:

  • /user/123
  • /user/456

Nginx 会对每个 URL 做哈希,然后按哈希结果分配到某一台服务器:
URL哈希值(示意)路由结果/user/123hash1后端服务器 A/user/456hash2后端服务器 B/user/123hash1还是后端服务器 A(保持一致)

这对于==缓存命中(同 URL 命中同缓存)==是非常有帮助的。

这个策略 不是 Nginx 默认内建的,需要依赖 第三方模块:ngx_http_upstream_hash_module

在很多发行版中,该模块默认未启用,必须通过编译 nginx 并添加参数来启用。
📌 使用步骤:

  • 确认模块是否已启用
    nginx -V
    查看输出中是否包含:
    --with-http_upstream_hash_module
    如果没有,就需要重新编译 nginx 时加上:
    ./configure --with-http_upstream_hash_module
  • 配置 upstream
http {
    upstream backend {
        hash $request_uri consistent;

        server 192.168.1.101:80;
        server 192.168.1.102:80;
    }

    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://backend;
        }
    }
}

🧠 参数解释:
配置含义hash $request_uri对请求的 URL(路径部分)做哈希consistent使用一致性哈希算法,减少后端变动时的扰动

你也可以基于其它变量进行哈希,如 arg_idurihost等。

fair

fair 策略的意思是:根据每台后端服务器响应时间的快慢,动态决定请求分发给谁
它不像轮询那样“你一下我一下”,而是更聪明地:

  • 哪台机器响应快,就优先用哪台;
  • 哪台响应慢,就分配得少;
  • 整体让用户体验“更公平”。

🧠 举个例子:
有两个后端:
后端服务器平均响应时间A (192.168.1.10)30 msB (192.168.1.11)300 ms

那么 fair 会更多地把请求分配给 A,而不是盲目轮询。
fair不是 Nginx 官方自带的,而是由 openresty 的作者早期开发的一个模块。
模块名:ngx_http_upstream_fair_module
📌 使用步骤:

  • 编译 nginx 时加入模块
./configure --add-module=/path/to/nginx-upstream-fair
make
make install
  • nginx.conf 配置方式
http {
    upstream backend {
        fair;

        server 192.168.1.101:80;
        server 192.168.1.102:80;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }
}

动静分离

✅ 什么是 Nginx 的“动静分离”?

动静分离 是指:
🔹“动态请求 交给后端应用服务器(如 Tomcat、SpringBoot)处理”,
🔹“静态资源(如图片、CSS、JS、HTML)直接由 Nginx 返回”。
🎯 举个最直观的例子:
你访问一个网站,比如博客页面:
arduino复制编辑http://www.example.com/post/123

它可能包含:

  • 页面结构和内容:由后端动态生成(HTML)
  • 页面样式:
    /css/style.css ✅ 静态
  • 页面脚本:
    /js/app.js ✅ 静态
  • 图片资源:
    /img/logo.png ✅ 静态

动静分离策略就是:
请求资源谁来处理?/post/123转发给后端服务处理/css/style.css由 Nginx 直接返回/img/logo.png由

Nginx 直接返回

✅ 为什么要做动静分离?
优势描述
⚡ 提升性能静态资源不走后端,响应更快、减少压力
🚫 降低耦合后端只负责业务逻辑,不处理资源加载
✅ 更易缓存静态资源可设置强缓存策略(expires)
🌍 支持 CDN可将静态资源部署到 CDN 边缘节点

✅ 一张图总结动静分离结构:

           [客户端浏览器]
                   |
                   v
              [Nginx服务器]
              /           \
       静态资源         动态请求
   (.css/.js/.png)     (/user/list)
       ↓                   ↓
Nginx本地返回         转发给Java后端

✅ Nginx 配置模板(前端+后端)

server {
    listen 80;
    server_name yourdomain.com;

    # 静态资源路径
    location / {
        root /usr/share/nginx/html;
        try_files $uri $uri/ /index.html;
    }

    # 接口代理
    location /api/ {
        proxy_pass http://localhost:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

以若依为例
✅ 最终:你需要的完整 nginx 配置长这样

server {
    listen 80;
    server_name 域名/localhost;

    # 静态资源 + 前端路由支持 比如前端打包文件放在/mnt/file/ruoyi
    location /ruoyi/ {
        root /mnt/file/ruoyi;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # 后端接口代理
    location /prod-api/ {
        proxy_pass http://localhost:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

前端打包配置
找到并设置:

module.exports = {
  NODE_ENV: '"production"',
  BASE_API: '"/prod-api"'     // 👈 设置请求路径前缀
}

🔁 表示:生产环境下,所有 axios 请求都会拼接 /prod-api

UrlRewrite

UrlRewrite(URL重写)是一种技术,用来修改客户端请求的URL路径,使其变得更友好、更简洁或者满足某些业务需求。

具体来说:

  • URL重写就是将用户访问的地址,转换成服务器内部实际处理的地址。
  • 它不会改变浏览器地址栏显示的URL(也可以做重定向改变),而是在服务器后台把请求转到另一个地址处理。

举几个常见例子:
1.让URL更简洁

比如把
http://example.com/product.jsp?id=123
重写成
http://example.com/product/123
用户看到的是简洁的URL,服务器内部处理的是带参数的真实地址。

1.隐藏真实路径
不暴露文件后缀或者真实目录结构,提高安全性。

2.SEO优化
搜索引擎喜欢简洁、关键词明确的URL。

简单示例(Nginx):

location /product/ {
    rewrite ^/product/([0-9]+)$ /product.jsp?id=$1 last;
}

访问 /product/123 时,实际请求转到 /product.jsp?id=123。
基本语法
rewrite 正则表达式 替换的URL [flag];

  • 正则表达式
    :匹配请求的 URL 路径。
  • 替换的URL
    :重写成的路径,可以带参数。
  • flag
    :可选参数,比如 last、permanent 等,控制重写后动作。

什么时候用 Nginx rewrite?

  • 你想用更漂亮的 URL 给用户访问。
  • 需要兼容老 URL 路径重定向。
  • 实现简单的路由转发。

以下三个场景,分别举个 Nginx rewrite 的具体例子,帮你理解怎么用。

1. 你想用更漂亮的 URL 给用户访问

把复杂带参数的 URL 改成简洁的伪静态 URL,用户看起来更友好。
例子:
用户访问:
http://example.com/article.php?id=123

改写成:
http://example.com/article/123

Nginx 配置:

location /article/ {
    rewrite ^/article/([0-9]+)$ /article.php?id=$1 last;
}

访问 /article/123,后台实际访问 /article.php?id=123。

2. 需要兼容老 URL 路径重定向

网站更新后,旧链接格式变了,想让访问老链接时自动跳转到新链接。
例子:
旧 URL:
http://example.com/old-page.html
新 URL:
http://example.com/new-page.html
Nginx 配置:

location = /old-page.html {
    rewrite ^ /new-page.html permanent;
}

访问 /old-page.html 时,返回 301 永久重定向跳转到 /new-page.html。

3. 实现简单的路由转发

根据 URL 路径,把请求转发到后端某个入口文件,比如单页应用入口。
例子:
所有路径都转发到 index.php,前端路由由页面自己处理。
Nginx 配置:

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

或者用 rewrite:

location / {
    rewrite ^/(.*)$ /index.php?route=$1 last;
}

访问 /user/profile,后台访问 /index.php?route=user/profile。

4. 完整示例(URL 重写(rewrite)和负载均衡(upstream)结合)

1. 定义后端服务器组(upstream)
upstream app_servers {
    # 轮询
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;

    # 也可以改成 least_conn 或 ip_hash 粘性:
    # least_conn;
    # ip_hash;
}

server {
    listen 80;
    server_name example.com;

    # 2. URL 美化重写 + 负载均衡代理
    location /article/ {
        # 把 /article/123 重写为后端实际路径 /article.php?id=123
        rewrite ^/article/([0-9]+)$ /article.php?id=$1 last;

        # 将重写后的请求代理到后端服务器组
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 3. 兼容老链接,重定向到新路径,同时负载均衡
    location = /old-page.html {
        # 先做 301 重定向
        rewrite ^ /new-page.html permanent;
    }

    location = /new-page.html {
        # 新页面也通过后端服务渲染
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 4. 前后端分离 SPA 路由:所有非静态资源都走统一入口
    location / {
        # 静态资源直接走 root
        try_files $uri $uri/ @backend;
    }

    location @backend {
        # SPA 入口,所有路由都转发给 index.php 或 index.html
        rewrite ^/(.*)$ /index.php?route=$1 last;
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 5. 静态资源
    location /static/ {
        root /var/www/html;   # 用 root,不走负载均衡
    }
}
步骤解析
1.upstream 定义
	upstream app_servers { … }:把多台后端节点(10.0.0.11、12、13)组成一个服务组。
	默认轮询(round‑robin),也可以 least_conn(最少连接)、ip_hash(基于客户端 IP 粘性)等。
2.URL Rewrite + 代理到 upstream
	在 location /article/ 里,先用 rewrite 把伪静态 URL 转成后端可识别的查询串。
	再用 proxy_pass http://app_servers;,让 Nginx 把请求分发到上面定义的后端组。
3.老链接兼容
	旧地址 /old-page.html 先 rewrite … permanent 做 301 重定向;
	新地址 /new-page.html 再 proxy_pass 到后端组。
4.SPA/统一路由入口
	所有不存在的文件路径都走 @backend,在这里统一 rewrite 成入口脚本,并负载均衡代理。
5.静态资源直出
	/static/ 一般直接用 root 从本地文件系统读取,不经过后端组;这样减轻后端压力。

防盗链配置

Nginx 的防盗链配置,主要是防止别的网站直接引用你网站上的图片、视频、PDF 等资源,偷你的带宽、资源。

🔒 什么是防盗链?

  • 比如你网站有图片:
    https://www.mywebsite.com/img/logo.png
  • 别的网站写了一段 HTML:
    <img src="https://www.mywebsite.com/img/logo.png">
  • 用户访问别的网站,却消耗了你服务器的流量 —— 这就是“盗链”。
    ✅ 防盗链的原理:检查请求头 Referer
  • 浏览器在请求资源时,会带上
    Referer 请求头(表示资源是从哪个页面跳转过来的)。
  • Nginx 可以根据
    Referer 判断是不是“本站页面”引用的资源。
    🚧 防盗链配置示例(只允许本站访问)
location ~* \.(jpg|jpeg|png|gif|mp4|webm|pdf)$ {
    valid_referers none blocked *.mywebsite.com mywebsite.com;

    if ($invalid_referer) {
        return 403;
    }
}

🔍 配置说明
指令作用valid_referers允许的 Referer 来源none表示 Referer 为空的请求(比如浏览器直接访问)也允许blocked表示一些不规范的 Referer 字段也允许(如代理请求时 referer 被屏蔽)*.mywebsite.com表示允许所有子域名访问$invalid_referer内置变量,表示当前请求是否是非法来源(不在 valid 列表中)
🚫 拒绝盗链后的处理方式
你可以选择:

  • 直接拒绝:
    return 403;
  • 或者跳转到替代图片:
    rewrite ^/img/.*\.(jpg|png)$ /img/nohotlink.jpg;
    ✅ 完整防盗链配置模板
location ~* \.(jpg|jpeg|png|gif|webp|mp4|pdf)$ {
    valid_referers none blocked *.mywebsite.com mywebsite.com;

    if ($invalid_referer) {
        # 拒绝非法请求
        return 403;
        # 或者返回替代资源
        # rewrite ^/.*$ /images/stop-stealing.jpg;
    }
}

网站公告

今日签到

点亮在社区的每一天
去签到