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