3.Nginx Location指令Nginx 的location指令是配置请求路由的核心机制用于定义如何处理不同的 URL 请求。通过配置location指令块可以决定客户端发来的请求 URI 如何处理是映射到本地文件还是转发给后端服务。3.1 基本语法location [|~|~*|^~|] uri { ... }位置可以在server块或location块内配置参数说明、~、~*、^~、为修饰符用于定义匹配方式uri是要匹配的请求路径3.2 修饰符类型及优先级Nginx 的 location 匹配分为五类优先级从高到低如下3.2.1 精确匹配语法location /path { ... }规则仅当请求路径与指定路径完全一致时生效区分大小写特点匹配成功后立即停止搜索优先级最高示例location /login { proxy_pass http://backend; # 仅匹配 /login不匹配 /login/ 或 /login.html }3.2.2 前缀匹配^~语法location ^~ /path { ... }规则对 URL 路径进行前缀匹配匹配成功后不再进行正则匹配特点在正则匹配之前执行但优先级低于精确匹配示例location ^~ /static/ { root /var/www; # 匹配所有以 /static/ 开头的请求 }3.2.3 正则匹配3.2.3.1 区分大小写~location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; # 匹配以 .php 结尾的请求区分大小写 }3.2.3.2 不区分大小写~*location ~* \.(gif|jpg|jpeg)$ { root /data/images; # 匹配图片文件不区分大小写 }3.3 普通前缀匹配无修饰符语法location /path { ... }规则进行前缀匹配但在正则匹配之后执行特点如果没有正则匹配命中则选择最长匹配的规则示例location /api/ { proxy_pass http://api_server; }3.4 通用匹配/语法location / { ... }规则匹配所有请求相当于 switch 中的 default特点优先级最低作为兜底配置示例location / { root /var/www/html; index index.html; }3.5 匹配顺序详解当 Nginx 接收到请求时按照以下顺序进行匹配先检查精确匹配检查前缀匹配^~找到最长的前缀匹配按配置顺序检查正则匹配、*如果没有正则匹配则使用最长的前缀匹配最后使用通用匹配/3.6 常用场景示例3.4.1 静态文件服务server { listen 80; server_name example.com; # 静态资源 location ^~ /static/ { root /var/www; expires 30d; } # 图片文件 location ~* \.(jpg|jpeg|png|gif|ico)$ { root /var/www/images; expires 1y; } # 默认处理 location / { proxy_pass http://backend; } }3.4.2API路由server { listen 80; server_name api.example.com; # 精确匹配健康检查 location /health { return 200 OK; add_header Content-Type text/plain; } # API v1 location /api/v1/ { proxy_pass http://api_v1_server; } # API v2 location /api/v2/ { proxy_pass http://api_v2_server; } }3.4.3 屏蔽特定路径# 禁止访问 .git 目录 location ~ /\.git { deny all; return 403; } # 禁止访问敏感文件 location ~* \.(env|log|sql)$ { deny all; return 403; }3.7 重要注意事项匹配顺序很重要配置文件中 location 的顺序会影响匹配结果特别是正则匹配proxy_pass 末尾斜杠有斜杠proxy_pass http://backend/;- 不携带 location 匹配的路径无斜杠proxy_pass http://backend;- 携带 location 匹配的路径调试技巧可以使用nginx -T命令查看完整的配置或在 location 块中添加add_header X-Location 规则名称;便于调试性能考虑精确匹配和前缀匹配性能最好正则匹配性能相对较低3.8 优先级冲突案例server { listen 80; server_name example.com; # 规则A: 精确匹配 location /login { echo 规则A: 精确匹配/login; } # 规则B: 前缀匹配 location ^~ /login { echo 规则B: 前缀匹配/login; } # 规则C: 正则匹配 location ~ /login { echo 规则C: 正则匹配/login; } # 规则D: 普通匹配 location /login { echo 规则D: 普通匹配/login; } }请求/login的匹配结果优先匹配规则A精确匹配规则B、C、D都不会执行通过合理配置 location 指令可以实现复杂的请求路由逻辑是 Nginx 配置中最重要的功能之一。理解其匹配规则和优先级对于正确配置 Nginx 服务器至关重要。4.Nginx Rewrite–Nginx URL重写4.1 什么是Rewrite?RewriteURL重写是Nginx中一个强大的功能模块用于将传入Web的请求重定向到其他URL的过程。简单来说就是当用户访问某个URL时Nginx会根据配置的规则将请求改写成另一个URL然后进行相应的处理。核心概念URL重定向将一个URL地址映射到另一个URL地址正则匹配基于Perl兼容正则表达式PCRE进行模式匹配透明性对用户来说URL重写通常是透明的除了301/302跳转4.2Rewrite的主要作用?安全性提升隐藏真实目录结构避免暴露服务器内部文件路径防止恶意攻击重写可疑的URL请求统一入口将所有请求重定向到统一的安全入口SEO优化URL权重集中将多个相似URL重定向到首选URL避免权重分散友好URL将动态URL重写为静态、易读的URL格式301永久重定向网站改版时保持搜索引擎排名网站维护平滑迁移网站结构调整时保持旧URL可用A/B测试将不同用户重定向到不同版本的页面负载均衡根据条件将请求重定向到不同的后端服务器4.3Rewrite指令语法4.3.1 基本语法rewrite regex replacement [flag];4.3.2 参数说明regex正则表达式用于匹配请求的URIreplacement重写后的URL路径flag标志位控制重写行为可选常用 flag 标记Flag说明HTTP状态码last停止当前rewrite重新搜索location内部重写break停止当前rewrite继续处理请求内部重写redirect临时重定向302permanent永久重定向3014.4Rewrite条件判断4.4.1~*正则匹配# 仅匹配以小写 .php 结尾的文件 location / { if ($request_uri ~* \.php$) { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } }说明~*表示区分大小写的正则匹配只匹配.php小写不匹配.PHP或.Php应用场景严格安全控制防止通过大小写绕过PHP处理4.4.2!~非正则匹配区分大小写# 如果请求路径不是以 /admin/ 开头区分大小写 location / { if ($request_uri !~ ^/admin/) { # 只有非管理员路径才应用此规则 add_header X-Non-Admin 1; } }说明!~表示不匹配指定的正则表达式区分大小写/Admin/会被认为是不匹配的因为是大写A应用场景区分大小写的访问控制4.4.3!~*非正则匹配不区分大小写# 如果请求路径不是以 /admin/ 开头不区分大小写location /{if($request_uri!~* ^/admin/){# 所有非管理员路径无论大小写都应用此规则add_header X-Non-Admin1;}}说明!~*表示不匹配指定的正则表达式不区分大小写/Admin/、/ADMIN/都会被认为是匹配的不会执行此规则应用场景用户友好的访问控制不区分大小写4.4.4-f和!-f用来判断是否存在文件# 如果文件存在则直接返回location /{if(-f$request_filename){# 文件存在直接返回break;}# 文件不存在重写到index.phprewrite ^/(.*)$ /index.php?path$1last;}说明-f检查文件是否存在!-f检查文件不存在应用场景单页面应用(SPA)的路由处理4.4.5-d和!-d用来判断是否存在目录# 如果目录存在则添加 trailing slashlocation /{if(-d$request_filename){rewrite ^/(.*[^/])$ /$1/ permanent;}}说明-d检查目录是否存在!-d检查目录不存在应用场景自动添加目录尾部斜杠4.4.6-e和!-e用来判断是否存在文件或目录# 如果文件或目录不存在则重定向到404页面location /{if(!-e$request_filename){rewrite ^ /404.html last;}}说明-e检查文件或目录是否存在!-e检查文件或目录不存在应用场景自定义404错误处理4.4.7-x和!-x用来判断是否存在文件是否可执行# 检查脚本是否可执行location /cgi-bin/{if(!-x$request_filename){return403;}# 如果可执行继续处理fastcgi_pass127.0.0.1:9000;include fastcgi_params;}5.HTTPS协议5.1 基本概念HTTPSHypertext Transfer Protocol Secure超文本传输安全协议是HTTP协议的安全版本。它在HTTP协议的基础上增加了SSL/TLSSecure Sockets Layer/Transport Layer Security加密层用于保护网络通信的安全性。HTTPS的核心目标是解决HTTP协议在数据传输过程中存在的安全缺陷。5.2HTTPS和HTTP的核心区别对比维度HTTPHTTPS安全性明文传输数据可被窃听、篡改加密传输保护数据机密性和完整性端口80端口443端口协议层应用层协议HTTP SSL/TLS安全层身份验证无身份验证机制通过数字证书验证服务器身份数据完整性无完整性校验通过MAC消息认证码确保数据完整性5.3HTTPS的工作原理HTTPS的安全性主要通过以下机制实现5.3.1 SSL/TLS握手过程客户端Hello客户端向服务器发起连接请求包含支持的加密套件和协议版本服务器Hello服务器选择加密套件返回服务器证书包含公钥证书验证客户端验证服务器证书的有效性通过CA证书链密钥交换客户端生成随机的预主密钥使用服务器的公钥加密预主密钥并发送给服务器服务器使用私钥解密获得预主密钥生成会话密钥双方基于预主密钥生成相同的对称加密密钥安全通信使用对称密钥进行加密数据传输5.3.2 加密机制HTTPS采用混合加密策略非对称加密仅用于证书验证和密钥交换阶段确保密钥安全传输对称加密用于实际数据传输效率高适合大量数据加密5.4HTTPS的优势与局限性5.4.1 优势数据安全保护用户隐私和敏感信息身份验证防止钓鱼网站和中间人攻击SEO友好搜索引擎优先收录HTTPS网站用户信任浏览器地址栏显示安全标识锁图标5.4.2 局限性性能开销加密解密过程增加CPU开销和延迟配置复杂需要正确配置证书和服务器成本部分高级证书需要付费并非万能不能防止应用层攻击如XSS、SQL注入5.5HTTPS模拟实操5.5.1 私有CA5.5.1.1创建证书[rootNginx-1 ~]# mkdir -p /etc/nginx/ssl[rootNginx-1 ~]# openssl req -utf8 -new -key /etc/nginx/ssl/server.key -x509 -days 365 -out /etc/nginx/ssl/server.crt[rootNginx-1 ~]# ll /etc/nginx/ssl/-rw-r--r--1root root1407Apr1517:23 server.crt -rw-r--r--1root root0Apr1517:10 server.csr -rw-r--r--1root root1708Apr1517:09 server.key5.5.1.2 创建网页并查看状态[rootNginx-1 ~]# mkdir /Test[rootNginx-1 ~]# echo HTTPS HTTPS HTTPS /Test/index.html[rootNginx-1 ~]# vim /etc/nginx/conf.d/Test.confserver{listen443ssl;server_name172.25.254.44;ssl_certificate /etc/nginx/ssl/server.crt;ssl_certificate_key /etc/nginx/ssl/server.key;location /{root /Test;index index.html;}}[rootNginx-1 ~]# nginx -t[rootNginx-1 ~]# systemctl restart nginx# 浏览器访问https://172.25.254.44