nginx-EW帮帮网

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_id、uri、host等。

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

nginx

nginx安装

nginx基础使用

目录结构

nginx配置与应用场景

worker_processes

worker_connections

include mime.types

default_type application/octet-stream

sendfile on

keepalive_timeout 65;

server

反向代理

反向代理

负载均衡默认使用轮询（round-robin）

weight权重

ip_hash

least_conn

url_hash

fair

动静分离

Nginx 直接返回

UrlRewrite

什么时候用 Nginx rewrite？

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

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

3. 实现简单的路由转发

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

步骤解析

防盗链配置

网站公告

今日签到

热门文章

最新发布