授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、三个数字先决定你往哪一边看1.1 地址敲下去回来的是一个三位数在自建靶场里把页面打开最容易被跳过的一行信息就在响应头的最前面一个三位数字后面跟一小段英文。它不解释原因也不给建议它只做一个判断——这一次请求服务端那边是怎么看的。多数人是在页面不对劲的时候才回头注意到它。页面是空白的、形状不对的、或者跳到了另一个地址这时候你翻出那一行看到三个数字然后卡住接下来该去翻自己写的那段地址还是去翻服务端的配置这个卡住的状态就是本文要解决的全部问题。那三个数字不是一句可有可无的提示它是服务端对被请求的那个动作给出的分类答复。读法对了方向就先对了一半。1.2 它描述的是答复不是你被怎么样了先纠正一个很常见的误读。有人在别处看到某个数字被告知它意味着你的请求被设备拦下来了。这类说法在本文取材的两份一手材料里找不到依据。本文只依据两份材料一份是 IANA 的官方状态码注册表一份是 RFC 9110。在这两份材料里每一个码的归属都写得很确定——它归在哪一类、叫什么名字、指向 RFC 的哪一小节。注册表里没有把任何一个码分配给某个中间设备拦截了你这种归属。所以看到一个不熟悉的数字时正确的动作不是替它编一个解释而是去注册表里查它登记成了什么。这句话会贯穿全文状态码是登记在案的条目不是形容词。1.3 本文只读不构造请求先把边界说明白本文只讲已经发生的返回该怎么读不讲怎么让某个码出现。凡是需要构造请求去把某个码凑出来的动作本文一概不写。文中出现的命令一律是只读的只看响应头不产生任何改变同时不在本机实测统一加标注。⚠️代码待验证curl-Ihttp://自建靶场地址/这条命令只做一件事把响应头取回来给你看。它不发送会改变状态的请求也不动服务端上的任何东西。之所以要专门强调这一点是因为同一类工具既能只读也能做别的——你选哪一种用法决定了这件事是在观察还是在动手。本文的每一次演示都停在观察这一侧。二、五类五句官方定义2.1 官方逐字定义长什么样IANA 那份注册表在最上面把五个类别各自定义了一遍。原文照抄如下英文逐字未作改动右侧是中文说明。官方逐字定义中文说明1xx: Informational - Request received, continuing process信息类请求已经收到处理还在继续2xx: Success - The action was successfully received, understood, and accepted成功类这个动作被成功接收、理解并接受3xx: Redirection - Further action must be taken in order to complete the request重定向类要完成这个请求还必须再采取进一步的动作4xx: Client Error - The request contains bad syntax or cannot be fulfilled客户端错误类请求本身含有坏的语法或者无法被满足5xx: Server Error - The server failed to fulfill an apparently valid request服务端错误类服务端没能满足一个看起来有效的请求这五句放在一起看有一个很值得注意的共同点它们描述的都是这次请求处在什么状态没有一句在描述谁对谁错。中文说明里出现的客户端错误服务端错误是类别名本身带的词是登记时就这么命名的不是额外给出的评价。初学阶段最容易做的一件事就是把类别名当成判词——看到带着错误字样的类就觉得是出问题了。回到原句上就不难发现官方给的是一句状态描述请求收到了、动作被接受了、还得再走一步、请求无法被满足、服务端没能满足。你要做的是把眼前的这三个数字对回其中一句而不是先给它加上情绪。2.2 第一位定类别后两位定具体那一个五个类别是按第一位数字分的这一点在定义里已经写死了1 开头就是第一句5 开头就是第五句。所以读到任何一个三位数你都能立刻完成第一次降维不用认全它先认第一位。⚠️代码待验证第一位数字 → 类别上面那五句里的一句 后两位数字 → 这一类里的具体那一个码 例读到 4xx 里的某个码 第一步第一位是 4落进请求含有坏的语法或无法被满足这一类 第二步再去看后两位是哪一条具体登记这个拆位动作看起来简单但它是本文后面所有判断的地基。因为类别那一层就已经把方向分好了——这一点第三章展开。顺带说一句类别这一层的稳定性。具体那一个一个的码是会增补的注册表里既有早就登记在那里的码也有后来从别的标准登进来的码而第一位对应的那五个类别是写在表头的那五句。所以在还没有把握的时候先只用到第一位是相对更稳的那一步。2.3 见到一个码先记五格给一个可以带走的动作以后每次遇到一个不认识的码先按下面这五格把它记下来能填几格填几格。⚠️代码待验证状态码______ 第一位______ → 类别______ 注册表里的名称______ 指向 RFC 9110 的哪一小节______ 这次请求里是谁在回应______最后两格最容易空着。前四格都能在注册表里查到唯独最后一格要靠你自己判断这次请求经过了什么。把查得到的先查实把查不到的明确标成还没弄清这两件事分开做能挡掉后面成片的瞎猜。三、第一位数字为什么能把方向分成两半3.1 4xx 那一句落点在请求上把 4xx 的官方定义单独拎出来逐字是4xx: Client Error - The request contains bad syntax or cannot be fulfilled重点在后半句。它说了两件事请求本身含有坏的语法或者请求无法被满足。注意这个或者——它没有说请求一定有问题只说不能满足它。也就是说4xx 只表态了一件事问题这一侧被放在请求上。它没有说请求写得难看也没有说请求带着攻击意图更没有说请求被谁拦下来了。3.2 5xx 那一句落点在看起来有效上再看 5xx逐字是5xx: Server Error - The server failed to fulfill an apparently valid request这一句里最值得多看两眼的词是apparently valid——看起来有效。它说明的是顺序请求先是被当作有效请求收下了然后服务端这边没能把它办成。责任落在没能满足这个动作上而不是落在请求不合格这个判断上。两句话摆在一起差别就出来了一个说请求这一侧有问题或者满足不了另一个说请求看起来没问题但服务端没办成。3.3 分成两半之后先查哪一边于是你手上就有了两条方向完全不同的路类别官方定义里的落点你要先看的那一侧4xxThe request contains bad syntax or cannot be fulfilled我这一次发出去的请求5xxThe server failed to fulfill an apparently valid request服务端那一侧的运行状态这就是第一位数字把方向分成两半的具体含义。它不是给你一个结论而是给你一个排序先查哪一侧后查哪一侧。⚠️代码待验证4xx → 先把我这一次的请求过一遍 地址对不对、方法对不对、带上来的东西对不对 5xx → 先把服务端那一侧过一遍 它当时在不在正常状态、它依赖的东西当时在不在 两半都不是结论只是顺序。 查完一半没有发现再去看另一半不要两边同时乱翻。这里必须补一句免责免得被误读成4xx 就一定是你错了。4xx 的官方定义里有一半说的是请求无法被满足——满足不了和写错了不是一回事。一个完全符合规范、语法干净的请求照样可能落进 4xx因为规则要求的那样东西在当时不成立。所以要记住的是归属方向不是谁的责任判决。四、两组最容易混的码4.1 401 与 403两个码不是一种情况的两种说法第一组是 401 和 403。它们在注册表里是两条独立的登记各自有名字、各自指向 RFC 9110 的不同小节码注册表里的名称指向 RFC 9110 的小节401Unauthorized15.5.2403Forbidden15.5.4两个名字是两个不同的词两个小节号也是两个不同的号。这里要提醒的是401 登记的名称字面是Unauthorized而它实际想要表达的那个位置和没有认证这件事绑在一起403 登记的名称是Forbidden落点在不被允许。名称只是登记用的标签你可以直译它但不能把直译当成完整定义——完整定义写在它们各自指向的那一小节里。混用的代价很实在这两个码指向服务端的两处不同判断如果把它们当成一回事的两种写法你排查时就会在错误的那一侧反复翻。4.2 404 与 405资源不在和方法不被接受第二组是 404 和 405。同样两条独立登记。404在注册表里的名称是Not Found指向 RFC 9110 的 15.5.5 小节405的名称是Method Not Allowed指向 15.5.6 小节。一个名字带的是没找到另一个带的是这个方法不被允许。从名称上直译一个说的是没找到一个说的是这个方法不被允许。这两句话问的是两个不同的问题前者问的是你要的那个东西在不在后者问的是你要对它做的那个动作在这个位置上允不允许。它们最容易混的地方在于现象相似页面都不给你想看的内容。但归属不同——一个落在资源一个落在方法。所以当你在这两个码之间摇摆时不要盯着页面看去看你这次用的是哪个方法、打的是哪个地址。这两条信息一对上码就分开了。4.3 顺带把一个改名说清楚413 的现行名称第三处容易踩的坑不是两个码的混淆而是一个码改了名字。413在注册表里的现行名称是Content Too Large它指向 RFC 9110 的 15.5.14 小节。你如果在旧资料里见过它另一个写法那是旧写法截至 2026-09-27注册表上登记的是Content Too Large。这条提醒的意义不在这个码本身而在于它证明了一件事注册表是会变的。一个名字可以被改一个码可以被废止一段区间可以被腾出来。所以我记住的那个版本永远只是某一时刻的版本需要的时候要回到表上确认一次。把本章这五条放成一张表顺手记一下码注册表里的名称指向 RFC 9110 的小节它和谁容易混401Unauthorized15.5.2403403Forbidden15.5.4401404Not Found15.5.5405405Method Not Allowed15.5.6404413Content Too Large15.5.14旧名称五、这是一张活着的表5.1 登记流程是 IETF Review别的标准也往里放码这份注册表既然是官方登记的那它就不是一次写完就封存的清单。它的登记走的是IETF Review流程而且是可扩展的除了 RFC 9110别的标准也可以往里面登记自己的码。截至 2026-09-27表里就有这样几条来自其他标准的码码注册表里的名称来自哪份标准207Multi-StatusRFC 4918429Too Many RequestsRFC 6585511Network Authentication RequiredRFC 6585这三条放在这里是在回答一个很实际的问题为什么有些码你在讲 HTTP 基础的那份材料里从头翻到尾也找不到因为它本来就不是从那里登进来的。它是被别人按同一个登记流程放进同一张表的。5.2 表里留着成段的空白第二个会让你翻不到的原因是空白。表里明确标着Unassigned的区间不止一小段而是一整片标记含义注册表里的例子Unassigned这一段没有分配给任何码105-199、227-299、309-399、419-420、452-499、512-599(Unused)留着的、明确不用的码306、418(OBSOLETED)已废止的码510 Not Extended这三种标记其实是三件不同的事Unassigned是这里没东西(Unused)是这里有位置但登记上写着不用(OBSOLETED)是曾经是码现在废止了。三者都指向同一个结论——这张表上有大量位置是没有含义的也有位置的含义被主动取消过。⚠️代码待验证Unassigned → 没分配不表示待解释 (Unused) → 留着的码不表示能用 (OBSOLETED) → 废止的码不表示还在生效 三种都不是你猜的那个意思。5.3 所以不认识某个码是很正常的事把这一章的三张表合起来看会得到一个挺让人松口气的结论你不认识某个码很可能不是因为你学得少而是因为那个位置本来就没有含义或者它的含义不在这份 RFC 里。这就把读码这件事的姿态定下来了认识的码按登记的名称和它指向的小节去读不认识的码去注册表里查它而不是替它编一个说法查完仍然对不上的明确记成还没弄清不要拿一个听起来顺耳的解释填进去。最后这条最难做到但也最重要。在状态码这一层猜错的成本比留空高得多——因为猜错会把你引到完全相反的那一侧去翻。还有一种情形值得单独提一句有些数字看起来很像某个你认识的码只差一位。这时候不要顺着相似去推——注册表是按条目登记的不是按形状登记的差一位就是另一条甚至可能正好落在那片标着没分配的区间里。形状上的相似在这里不构成任何证据。配套资料把这份注册表的五个类别、常见码的名称与小节号、以及本文提到的那几种登记标记整理成了一页可以随手查的速查表放在资料包里扫码即可获取六、最反直觉的一条304 不在成功那一类6.1 200 和 304被分在了两处如果让你猜一个东西没变不用重新传的结果应该归进成功那一类还是别的类直觉多半会选成功。但注册表把它们分在了两处码注册表里的名称归在哪一类指向 RFC 9110 的小节200OK2xx成功类15.3.1304Not Modified3xx重定向类15.4.5200 在成功类里这符合直觉。而304 Not Modified——它属于重定向这一类3xx不属于成功这一类。这是本文最想让你记住的一条因为它最容易顶着你原有的直觉。6.2 为什么它会落在重定向这一类回到第五章开头那五句官方定义。3xx 那一句逐字是3xx: Redirection - Further action must be taken in order to complete the request关键在Further action must be taken——要完成这个请求还必须再采取进一步的动作。现在再看 304 这个结果的样子服务端告诉客户端你要的那个东西没变。这句话本身并没有把请求完成掉它是在提示下一步——既然没变客户端接下来要做的动作就和正常取回内容不一样。归类是按请求有没有走到终点来分的不是按这次沟通顺不顺利来分的。沟通很顺利但请求还没走完所以它落在 3xx。⚠️代码待验证curl-Ihttp://自建靶场地址/用这个只读动作取回响应头时你要找的就是最前面那三个数字。如果你判断某个码的归属时把 200 和 304 归成了同一类那么 3xx 的那句定义就该再读一遍——它是按还要不要走下一步来分类的。6.3 由此得到的一条读法把这一章压成一句话判断一个码归在哪一类不看结果顺不顺利看请求有没有走完。这条读法的价值不只在 304 这一处。它其实是在校正一个更底层的习惯我们习惯用好/坏给数字贴标签而注册表用的是状态。2xx 是动作被接受3xx 是还得再走一步这两个描述之间没有褒贬只有进度的差别。把这个前提换过来你在 4xx、5xx 上的判断也会跟着稳一些——它们同样是在描述状态不是在下判决。这里还有一个副产品既然 3xx 那句话是在说还得再走一步那么落进这一类的就不止 304 一个。地址被换到别处、需要客户端再走一趟的结果也都在这一格里。它们的共同点不是结果长得像而是同一个判断这个请求还没走完。七、读响应时你真正要看的是两样东西7.1 官方那一句口径RFC 9110 里有一句话把客户端读响应这件事说得非常干净逐字是The client examines received responses to see if its intentions were carried out, determining what to do next based on the status codes and content received.翻成中文客户端检查收到的响应看看自己的意图有没有被执行并依据收到的状态码与内容来决定下一步做什么。这句话里有两个词被并列放在了一起状态码和内容。也就是说读响应不是只看那三个数字也不是只看页面里写了什么而是两样一起看。状态码告诉你这一层处在什么状态内容告诉你这一层之外还有什么信息。这也是前面几章反复强调不该替码猜意思的原因——猜出来的意思会盖住你本来该从内容里读到的东西。7.2 一张读码顺序表把全文的读法收成一张顺序表下次遇到数字就照着走。顺序看什么这一格回答的问题1那个三位数本身这次请求处在什么状态2第一位数字它归在哪一类要往哪一侧看3注册表里这个码的名称它登记的名字是什么不是我以为的名字4它指向的 RFC 9110 小节完整定义在哪一段5响应里的内容意图有没有被执行下一步做什么走到第三步时如果发现表上没有这一条就停在第三步——回去看表本身别往下猜。7.3 本文使用限制写到这里把本文的边界交代清楚免得被误读本文只做已经发生的返回该怎么读这一件事不给任何构造请求去触发某个码的做法。文中出现的命令一律是只读的观察动作且均未在本机实际运行一律标了代码待验证请在你自己的隔离环境里核实之后再决定要不要用。本文不重讲请求在链路上经过的过程、不重讲端口与访问路径那几层——它们各自属于别的轴本文只在必要处一句话带过不重复展开。本文不含任何攻击步骤、利用载荷、绕过手法、具体报错文本与量级数字也不把任何一个码解释成被某个设备拦截。文中所有官方口径均照抄原文英文逐字引用并附中文说明核验日期逐条见附表 A。这注册表与 RFC 是会更新的本文引用的是核验日当天看到的内容动手前请以你手上那一份为准。本文对码的归类只依据注册表登记的类别与名称至于某个码在某个具体系统里由哪一段程序发出超出了本文的取材范围本文不作推断。配套资料第七章这张读码顺序表连同五个类别的官方定义原文、两组易混码的对照一并放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表核验日期逐条标注于下表英文原文逐字引用未作改写。注册表与 RFC 会更新建议隔一段时间按同一出处复检一次。#本文写出的事实照官方口径官方一手出处核验日期本文位置11xx: Informational - Request received, continuing processIANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27二、2.122xx: Success - The action was successfully received, understood, and acceptedIANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27二、2.133xx: Redirection - Further action must be taken in order to complete the requestIANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27二、2.1、六、6.244xx: Client Error - The request contains bad syntax or cannot be fulfilledIANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27三、3.1、3.355xx: Server Error - The server failed to fulfill an apparently valid requestIANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27三、3.2、3.36注册表按 IETF Review 流程登记、是可扩展的除 RFC 9110 外其他标准也可登记自己的码IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.17207 Multi-Status来自 RFC 4918IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.18429 Too Many Requests、511 Network Authentication Required来自 RFC 6585IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.19注册表中标为Unassigned的区间105-199、227-299、309-399、419-420、452-499、512-599IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.210注册表中标为(Unused)的码306、418IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.211注册表中510 Not Extended标为(OBSOLETED)IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.212200 OK指向 RFC 9110 第 15.3.1 节IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27六、6.113301 Moved Permanently→15.4.2、302 Found→15.4.3、304 Not Modified→15.4.5IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27六、6.1、4.114400 Bad Request→15.5.1、401 Unauthorized→15.5.2、403 Forbidden→15.5.4、404 Not Found→15.5.5、405 Method Not Allowed→15.5.6、408 Request Timeout→15.5.9IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27四、4.1、4.215413的现行名称是Content Too Large指向 RFC 9110 第 15.5.14 节IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27四、4.316429 Too Many Requests指向 RFC 6585IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27四、4.3、五、5.117500 Internal Server Error→15.6.1、502 Bad Gateway→15.6.3、503 Service Unavailable→15.6.4、504 Gateway Timeout→15.6.5、505 HTTP Version Not Supported→15.6.6IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27三、3.3、七、7.218The client examines received responses to see if its intentions were carried out, determining what to do next based on the status codes and content received.RFC 9110 HTTP SemanticsIETF 标准2022 年 6 月— https://www.rfc-editor.org/rfc/rfc9110.html2026-09-27七、7.119注册表页面标注 Last Updated 2025-09-15其 Reference 指向 RFC 9110 第 16.2.1 节IANA HTTP Status Code Registry — https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml2026-09-27五、5.1附表 B术语速查表术语是什么为什么在本文里重要状态码层服务端把处理结果交回客户端时给出的那三位数字这一层它不解释原因只做分类所以读法比记忆更要紧本文整篇都在讲这一层类别由第一位数字决定的五个大类1xx 到 5xx第一位一读出来排查方向就先分好了IANA 注册表IANA 维护的官方 HTTP 状态码登记表码的名称、类别、指向的小节都以它为准认不认识的裁决权在它这里RFC 9110讲 HTTP 语义的 IETF 标准注册表里每个码都指向它的一小节完整定义在那里IETF Review注册表用的登记流程它说明这张表是可扩展的别的标准也能往里面登记Unassigned注册表上没分配给任何码的区间翻不到某个码可能只是这一位没分配不是你没学会(Unused)留着的、明确不用的码有位置不等于有含义(OBSOLETED)已废止的码位置的含义可以被取消我以前见过不等于现在还生效现行名称注册表上此刻登记的名称413的现行名称是Content Too Large老写法不作数只读观察动作只取回信息、不产生任何改变的动作本文给出的全部命令都属于这一类核验日期引用的官方口径是哪一天看到的表与 RFC 会更新写明日期才能判断这条口径还成不成立写在最后这篇用到的资料写这篇文章时我把 IANA 那份注册表从头到尾过了一遍——五个类别的定义、常见码的名称与小节号、还有成片标着没分配和已废止的位置又回头对照了 RFC 9110 里讲客户端读响应的那一句把看到一个数字该往哪边看理成了一张顺序表顺手也整理了几份配套的东西状态码速查表五个类别的官方定义原文、常见码的名称与 RFC 9110 小节号以及登记表上那几种标记的含义Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看状态码速查表那一份——先把认识的码和不认识的码分开不认识的直接回注册表查比凭着印象猜一个意思要稳得多。
