Nginx基础教程（38）Nginx HTTP请求处理之请求行：Nginx的“读心术”！看它如何像拆快递一样，把HTTP请求行扒个精光！

开场白：那个你熟悉又陌生的“请求行”

嘿，各位后端、运维以及即将秃头的程序员朋友们！咱们每天都在跟Nginx打交道，把它当成一个任劳任怨的流量转发工具人。但你有没有想过，当一份来自客户端（比如浏览器）的“心意”（HTTP请求）跋山涉水来到Nginx面前时，这位老哥第一件事是干嘛？

是立刻埋头苦干，直接转发吗？No, no, no!

它的第一件事，是像个侦探一样，把这份“心意”的外包装——也就是HTTP请求行——仔仔细细地端详一遍，扒个底朝天！

今天，咱们不聊那些虚头巴脑的概念，就来一场关于Nginx如何处理HTTP请求行的深度“吃瓜”之旅。我会用最口语化、最不AI的方式，带你看看Nginx是怎么“读懂”客户端想干嘛的。保证你看完直呼：“原来这玩意儿是这么回事！”

第一章：前方高能！认识一下HTTP请求的“头号文件”——请求行

想象一下，你是个快递站的分拣员（Nginx），每天要处理成千上万个包裹（HTTP请求）。每个包裹外面都贴着一张核心面单，上面写着最最关键的信息。这张面单，就是HTTP请求中的 “请求行” 。

它长啥样？就一行字，简单粗暴，通常是这样式儿的：

GET /index.html?name=Tony&age=18 HTTP/1.1

看出来了吗？就这一行，包含了三个天大的秘密，我们用“人话”翻译一下：

1. GET (请求方法)：哥们，我想拿点东西。 —— 这说明了客户的意图。是来拿东西的（GET）？还是来寄东西的（POST）？或者是来退货的（DELETE）？
2. /index.html?name=Tony&age=18 (URI)：我要拿的货品编号是“index.html”，另外我还备注了要求，要名字叫Tony，年龄18的。 —— 这指明了客户想要的资源在哪里，以及附带的额外要求（查询参数）。
3. HTTP/1.1 (协议版本)：我用的“沟通暗号”是1.1版本的，你得用这个版本回我话。 —— 这规定了我们这次对话要遵循的规则。

Nginx拿到这个“面单”后，它的核心工作就是：快速、准确地解析这一行，然后把里面的信息提取出来，变成自己内部能理解的变量，后续所有的决策（转发给谁、怎么改写、是否拒绝）都基于这些变量。

所以，理解Nginx处理请求行，本质上就是理解它如何解析和利用这三个部分。

第二章：庖丁解牛！Nginx的“解剖课”与它的变量宝库

Nginx把请求行解析后，会把里面的“肉”一块块剔出来，分门别类地放进它自己的“变量冰箱”里。以后想用哪块，直接拿出来“炒菜”就行。

我们来认识一下这些关键的“食材”：

1. 关于“意图”（请求方法）：$request_method

这最简单。客户想干嘛，原封不动存进来。

• 如果请求是 GET，$request_method 的值就是 GET。
• 如果是 POST，值就是 POST。

实战骚操作：
比如你家网站只允许“拿”（GET）和“寄”（POST），不允许“删”（DELETE）。你就可以在Nginx里设个卡：

location /api/ {
    if ($request_method !~ ^(GET|POST)$ ) {
        return 405 "Method Not Allowed"; # 直接一个405错误怼回去
    }
    # 如果是GET或POST，就正常处理...
}

2. 关于“资源地址”（URI）：这里是重头戏，变量多得让人头秃！

URI这玩意儿水比较深，Nginx为了满足你各种变态的需求，把它拆得稀碎。咱们重点讲几个最容易混淆的“孪生兄弟”。

• $request_uri： 最原始的“全家桶”
  这个变量保存了从客户端收到的、原汁原味、未经任何加工的完整URI。包括最前面的/，以及后面的所有查询参数。

• • 例子：对于 /index.html?name=Tony&age=18，$request_uri 就是 /index.html?name=Tony&age=18。
  • 特点： 绝对保真。常用于记录原始访问日志，或者需要将原始URL透传给后端应用时。

• $uri 或 $document_uri： 被“净化”过的“原味鸡”
  这俩是同一个东西（别名）。它代表的是经过Nginx“加工”后的、标准化了的URI。

• • 它会怎么做？

• • • 自动解码被URL编码的字符（比如 %20 变回空格）。
    • 解析 .. 和 . 相对路径。
    • 最重要的是，它会去掉后面的查询字符串 ?xxx。

• • 例子：对于 /index.html?name=Tony&age=18，$uri 的值就是 /index.html。
  • 特点： 干净，常用于内部文件路径匹配，比如 try_files 指令。

“全家桶” vs “原味鸡”，到底用哪个？

打个比方：

• 你想知道客户到底点了啥（用于记录或原样转发），用 $request_uri (全家桶)。
• 你想自己动手做这道菜（比如根据URI找对应的文件），用 $uri (原味鸡)。
• $args： 单独的“调料包”
  这个就是查询参数部分，不带前面的 ?。

• • 例子：对于 /index.html?name=Tony&age=18，$args 就是 name=Tony&age=18。

• $arg_XXX： 精准拿取“某一种调料”
  这是Nginx最贴心的功能之一！你可以通过 $arg_参数名 直接获取某个特定参数的值。

# 如果用户没传token参数，就返回403
if ($arg_token = "") {
    return 403 "You need a token!";
}

• • 例子：对于上面的请求，$arg_name 的值就是 Tony，$arg_age 的值就是 18。
  • 骚操作： 实现简单的条件判断。

第三章：神兵天降！用rewrite指令玩转请求行，实现“地址魔术”

好了，认识了这些变量，我们就可以开始搞事情了！Nginx最强大的功能之一——URL重写，其核心就是修改 $uri 这个变量。而干这事的，就是 rewrite 指令。

rewrite 的基本语法是：

rewrite 正则表达式 替换字符串 [标志位];

它就像一个魔术师，看着当前的 $uri，心想：“嗯，这个地址我不太喜欢，给我变个样子！”

实战场景大赏：

场景1：经典旧URL跳转到新URL（301永久重定向）
你的文章路径从 /old-post/123 改为了 /archives/123。

location /old-post/ {
    rewrite ^/old-post/(.*)$ /archives/$1 permanent;
    # 正则 ^/old-post/(.*)$ 会匹配 /old-post/123，并将 123 捕获到 $1 里。
    # 替换字符串是 /archives/$1，结果就是 /archives/123。
    # `permanent` 标志位告诉浏览器，这是永久移动，返回301状态码。
}

场景2：实现“伪静态”，让动态URL看起来像静态文件
你真实的接口是 /api/user.php?id=100，但你想让它看起来更优雅，像 /user/100。

location /user/ {
    # 当访问 /user/100 时，内部将其重写为 /api/user.php?id=100
    rewrite ^/user/(\d+)$ /api/user.php?id=$1 last;
    # `last` 标志位表示重写后，用新的URI重新在location块里寻找匹配。
}

这样，用户访问的是漂亮的 /user/100，而Nginx内部处理的却是 /api/user.php?id=100，前后端分离和SEO优化利器！

场景3：强制全站使用HTTPS

server {
    listen 80;
    server_name yourdomain.com;
    # 如果请求不是HTTPS，就重写URL，强制跳转到HTTPS版本
    rewrite ^(.*)$ https://yourdomain.com$1 permanent;
}

第四章：黄金搭档！try_files与$uri的完美协奏曲

如果说 rewrite 是主动出击的魔术师，那 try_files 就是一位细心周到的“备胎查找员”。它通常和 $uri 变量紧密合作。

try_files 的语法是：

try_files 文件1 文件2 ... 回退选项;

它的工作逻辑是：“让我看看 $uri 这个文件存不存在？不存在？那我再看看你给的备胎1存不存在？还不行？再看看备胎2……如果所有备胎都不行，那我就只能执行最后的回退方案了（比如返回404，或者转发给后端）。”

实战场景：搞定单页应用(SPA)和历史路由模式
这是前端的Vue、React等项目部署时最常见的配置问题。

假设你的SPA项目只有一个真实的HTML文件 index.html，所有像 /home, /about 这样的路由都是前端JavaScript管理的。如果用户直接访问 yoursite.com/about，Nginx会在磁盘上找 /about 这个文件，当然找不到，于是返回404。

怎么办？用 try_files！

server {
    root /var/www/my-spa/dist; # 你的SPA项目构建后的目录
    index index.html;

    location / {
        # 神奇的三步走：
        try_files $uri $uri/ /index.html;
        # 1. 先尝试找 $uri 对应的真实文件（比如CSS，JS，图片）
        # 2. 如果没找到，尝试找 $uri 对应的目录（一般用不上）
        # 3. 如果还没找到，就把请求交给 /index.html 来处理！
    }
}

这样一来，无论是访问 /（能找到 index.html），还是直接访问 /about（找不到文件，回退到 index.html），最终都会由同一个HTML文件接手，前端路由就能正常工作了。完美！

第五章：完整示例！从“翻车”到“救火”的全流程实录

光说不练假把式，我们来搭建一个完整的、有点“戏精”的配置场景。

背景故事： 我们有一个个人博客，原来文章路径是 /blog.php?id=xxx，太丑了！我们决定升级成优雅的 /post/xxx。同时，还要做好SPA的部署。

初始配置（翻车现场）：

server {
    listen 80;
    server_name myblog.com;
    root /home/www/blog;

    location / {
        index index.html;
    }

    # 老的博客接口
    location ~ \.php$ {
        # ... 配置PHP-FPM处理逻辑
    }
}

现在访问 /post/123，Nginx只会一脸懵逼地返回404。

救火配置（终极版）：

server {
    listen 80;
    server_name myblog.com;
    root /home/www/blog;
    index index.html;

    # 1. 首先，处理那些直接访问老URL的顽固用户，把他们301到新地址
    location /blog.php {
        if ($args ~* "^id=(\d+)") {
            rewrite ^ /post/%1? permanent; # %1 是对前面正则(\d+)的捕获
        }
    }

    # 2. 核心location：处理优雅的新URL和SPA
    location / {
        # 先尝试为新的 /post/123 这样的URL，重写为后台真正的处理脚本
        rewrite ^/post/(\d+)$ /app/article.php?article_id=$1 last;

        # 然后，使用try_files处理静态资源和SPA回退
        try_files $uri $uri/ /index.html;
    }

    # 3. 处理后端PHP脚本（经过rewrite后，URI变成了/article.php，会匹配到这里）
    location ~ \.php$ {
        # 确保这个文件存在，否则会报错
        try_files $uri =404;
        # ... 其他FastCGI配置
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.0-fpm.sock;
    }

    # 4. 记录日志时，把原始请求和最终处理的URI都记下来，方便排查
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" '
                    'Original: "$request_uri" -> Final: "$uri"';
    access_log /var/log/nginx/access.log main;
}

这个配置是如何工作的？让我们跟踪一次访问：

1. 用户访问：https://myblog.com/post/456
2. Nginx收到请求，请求行是：GET /post/456 HTTP/1.1
3. 进入 location / 块。
4. rewrite 规则生效，将 $uri 从 /post/456 内部修改为 /app/article.php?article_id=456。[last] 标志让Nginx拿着新URI重新寻找匹配的 location。
5. 新URI /app/article.php 匹配到了 location ~ \.php$ 块。
6. 该location块内的 try_files $uri =404; 检查 /app/article.php 这个文件是否存在。
7. 存在，于是将请求通过FastCGI传递给PHP-FPM处理。
8. PHP-FPM执行脚本，返回文章内容。
9. Nginx将内容返回给用户，用户愉快地看到了文章。

而如果用户访问的是一个前端路由，比如 /dashboard/settings，rewrite 规则不匹配，try_files 也找不到对应的文件或目录，最终回退到 /index.html，SPA应用顺利加载。

尾声：从“会用”到“玩转”

看到这里，你是不是对Nginx这个“请求翻译官”有了全新的认识？它不再是一个黑盒，而是一个你可以精确操控的精密仪器。

处理HTTP请求行，是Nginx一切高级玩法的基石。$request_uri, $uri, $args 这些变量是你的眼睛，rewrite 和 try_files 是你的双手。当你清楚地知道Nginx眼里看到的请求是什么样子时，你就能写出无比精准和强大的配置规则。

现在，就打开你的Nginx配置文件，别再只会写 proxy_pass 了，试着用今天学到的“读心术”和“地址魔术”，去折腾点新花样吧！记住，唯一的限制，就是你的想象力（和你的测试服务器能不能扛得住你的折腾）。