群青色黑洞做过CTF的朋友应该都有一个体会：Web方向的知识点又杂又散，今天碰一个SQL注入，明天碰一个文件上传，后天又来个反序列化，学了半天总觉得没形成体系。CTFHub这个平台的好处就在于它把Web方向拆成了技能树，一级一级往上点，而整个Web技能树的根节点之一，就是HTTP协议这一关。我一开始也觉得，HTTP协议不就是请求和响应嘛，有什么好学的？结果真正刷完CTFHub的HTTP协议模块才发现，这个模块几乎是把Web层面最容易忽略的几个“盲区”挨个戳了一遍。这篇文章就把我在通关过程中的完整思路、解题手法和踩坑记录整理出来，给正准备刷这个模块的朋友做个参考。
这个模块整体难度不大，定位是“Web前置技能”，意思就是说你连这里都过不去，后面那些题目大概率也会卡壳。适合刚入门CTF、还没系统学过HTTP协议细节的选手，也适合那些学了理论但没做过实际练习的人。整篇文章会按照题目类型逐题拆解，从请求方法改造、Base64认证、响应包分析、抓包看Cookie，到伪造IP头、处理302跳转，每一题我都会讲清楚“为什么这么解”，而不只是给你一个答案。
1. 先聊清楚：为什么HTTP协议会被单独做成一个关卡模块
1.1 HTTP协议在CTF Web题目里的位置
CTF的Web题目虽然五花八门，但几乎所有攻击最终都要落在HTTP请求上。SQL注入是往HTTP参数里塞Payload，文件上传是构造一个特殊的HTTP请求体，SSRF是让服务器发HTTP请求，XSS则是在用户浏览器和服务器之间的HTTP交互里做文章。换句话说，HTTP协议就是你打Web题的“通用语言”，不熟悉这套语言，拿到题目有时候连“从哪下手”都不知道。
你去看CTFHub的技能树就会注意到，它把Web前置技能放在很靠前的位置，而HTTP协议又排在这个前置技能列表的前面。这其实是平台在设计时故意安排的：先让你在HTTP协议上吃点小亏，明白“请求包”和“响应包”里面到处都是信息，然后你再去学什么文件上传、命令注入，思路才会打开。很多新手上来就急着刷SQL注入，结果连Burp Suite都没打开过，看不懂原始请求长什么样，刷题效率自然特别低。
1.2 这个模块的整体设计逻辑：由浅入深的“HTTP体检”
把CTFHub的HTTP协议整个模块刷下来，你会发现它安排的顺序有自己的逻辑。它不是上来就考你什么复杂的安全漏洞，而是先让你学会改请求方法，然后再让你看响应包里的源码和响应头，接着才是认证绕过、抓包、Cookie操作、伪造请求头、处理重定向。每一步都在逼你养成一个习惯：拿到一个Web题目，先别急着在页面上瞎点，打开抓包工具，把请求和响应从头到尾看一遍。
这个习惯在题目里体现得非常直接。有的题flag就躺在响应头里，有的题需要你把请求方法改成题目指定的奇怪方法，有的题则需要你跟着重定向走一步但中途拦下来看信息。刷完之后你会明显感觉到，自己看“流量”的敏感度高了一个档次。后面你再去学更复杂的Web漏洞，就会很自然地联想到HTTP层面的关键点。所以这一关更像是一次带体检性质的专项训练，目的不是为难你，而是补上大多数人容易漏掉的基础功。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开打之前：工具与环境准备
2.1 浏览器开发者工具：最轻量的抓包方式
刷这个模块，个人建议从浏览器开发者工具起步。按F12打开开发者工具，切到“网络”(Network)标签页，刷新一下题目页面，你会看到所有请求的列表。点击任意一个请求，能看到完整的请求URL、请求方法、状态码、请求头(Request Headers)、响应头(Response Headers)和响应体(Response Body)。对于CTFHub这类平台来说，页面本身没有复杂的加密，开发者工具已经完全够用。
这里有一个很小但容易卡住新手的细节：如果你要在开发者工具里修改请求方法或者请求头，直接在“网络”标签页里改是不行的。开发者工具主要用来“看”，要“改”得用它的编辑重放功能，或者直接转到浏览器自带的命令行工具。Chrome的Fetch API可以辅助构造请求，Firefox的开发者工具则支持直接编辑和重发请求，右键点击请求就能“编辑并重放”。我用的时候感觉Firefox在这一点上更顺手，不过大多数人习惯用Chrome，那也没关系，备上Burp Suite就能解决修改的问题。
2.2 装上Burp Suite，后面几十关都用得上
如果你打算认真刷CTFHub后续的Web技能树，那Burp Suite基本是标配。这个工具的作用是充当浏览器和服务器之间的代理，你浏览器的流量都会经过它，你可以先拦截下来、随意修改，再放行出去。修改请求方法是常规操作，修改请求头、Cookie、重放请求、看历史包，这些功能在后续题目里会反复用到。
Burp Suite的免费社区版(Community Edition)就够用了，我用的就是社区版。启动后默认监听127.0.0.1:8080，把浏览器代理设置好，再装上对应的CA证书（这样HTTPS流量也能看到明文）。CTFHub上面有不少题目是HTTPS的，所以这一步别省。设置好之后你会在Burp的Proxy > HTTP history里看到所有请求记录，右键可以Send to Repeater，然后在Repeater标签页里改内容、点Send。改完看右侧响应，效率比在浏览器里折腾高很多。
2.3 先补一点基础知识：HTTP请求和响应各自长什么样
这一关能顺利刷下来，你需要对HTTP请求和响应有一个最基础的结构认知，不需要学多深，能看懂字段就行。
一个HTTP请求，主要包含三块：请求行、请求头、请求体。请求行最显眼，开头是请求方法（METHOD），中间是路径（Path），末尾是协议版本（HTTP/1.1），比如 GET /index.php HTTP/1.1。请求头是很多行“名字: 值”，比如 Host: challenge.ctfhub.com、User-Agent: Mozilla/5.0、Cookie: admin=0。请求体通常出现在POST请求里，跟在空行后面，是你要提交的参数数据。
一个HTTP响应，同样有三块：状态行、响应头、响应体。状态行里的状态码特别重要，200表示正常，302表示重定向，401表示未认证，403表示禁止访问。响应头里可能会有 Location（告诉你要跳到哪）、Set-Cookie（让你设置Cookie）、Content-Type（返回内容类型）等字段。响应体就是网页源码或者接口返回的数据，很多题目的flag就藏在响应体里，但因为浏览器渲染过，你肉眼看的是“页面”，而不是“源码”，所以一定要记住查看“原始响应”这个操作。
3. 逐题通关实录：HTTP协议模块的完整思路
3.1 请求方式：改一个方法就能拿flag
这个模块的第一道题通常叫“请求方式”，题目会给一个页面，上面写着“只能使用GET方法请求”。大多数人第一反应是老实打开浏览器，输入地址访问，然后页面提示“请使用CTFB方法”。这个时候你得反应过来：题目不是让你带什么参数，而是让你把一个不常见的请求方法发给服务器。所谓CTFB方法是题目自己造的一个方法名，常规工具里一般没有，你需要手动把请求行里的 GET /index.php HTTP/1.1 改成 CTFB /index.php HTTP/1.1。
我一般是这样操作的：开着Burp，刷新页面，抓到 GET /index.php 的请求包，右键Send to Repeater，然后在Repeater里把请求行开头的 GET 改成 CTFB，点Send。如果服务器接受的请求方法名匹配，响应包里面就会出现flag。这个操作背后有个小知识点：HTTP协议规定请求方法是由客户端指定的一个“动词”，Web服务器的代码通常会检查这个动词是否符合预期，但很多开发者只检查了“是否等于GET/POST”，却忘了非标准方法可能被后端逻辑放过。这里不是要利用什么严重漏洞，只是为了让你建立起“请求方法是可以任意修改的”这个认知。
之所以强调用Burp而不是直接在浏览器里访问，是因为浏览器不会让你随便输入一个自定义方法——它在输入框里只会发出GET或者POST。所以你必须有代理工具，学会拦截和改写。这道题本身不难，核心价值在于逼你迈出“从浏览器用户到请求构造者”的第一步。
3.2 基础认证：Base64背后的认证逻辑
下一类比较典型的题是“基础认证”。打开题目页面，浏览器会弹出一个原生的认证框，要求输入用户名和密码。没用过这种认证方式的人可能一脸懵：这不是页面表单，是一个HTTP层面的认证，叫HTTP Basic Authentication，Abbreviation叫Basic Auth。
Basic Auth的工作机制很简单：浏览器弹出输入框之后，你输入用户名和密码，浏览器会把 用户名:密码 拼在一起，然后做一次Base64编码，放到请求头里，形如 Authorization: Basic YWRtaW46YWRtaW4=。服务器收到后解码，比对是否等于正确的凭证。
CTFHub这个环境里，这类题有时候会给你提示，比如“用户名是admin”、“密码是admin”，或者干脆让你看题目页面里的其他线索。你直接填了可能正确，也可能不对。我建议的做法是：先用Burp拦截登录请求，看看浏览器到底发送了什么，再根据提示去修改。如果页面给的提示是别的用户名密码，直接填进去点“尝试登录”就行；如果没给线索，你也可以从页面标题、注释、响应头里找。这里有个小建议：别人告诉你Basic Auth和Base64有关系，也不要过于轻信“解码就能拿到密码”。编码不等于加密，这是这一关想传达的重点，你捕获一个合法请求后，把Authorization值复制出来，放到网上随手一解，立刻能看到原始格式的 用户名:密码。
这道题的实际难点不在“怎么解”，而在于你能不能意识到“这个弹窗不是网页里的表单，而是HTTP协议层面的东西”。很多人卡在这里，是因为他们在网页源码里找了半天账号密码输入框，却忘了去抓包看请求头。所以一看到认证弹窗，条件反射就应该想到打开Burp，用明文请求来观察和修改。
3.3 响应包源代码：别只知道看页面
有一类题名字很直白，叫“响应包源代码”。题目页面打开后，你看到一个很简单的网页，直接右键查看源代码，可能会发现注释里写着 <!-- flag就在这里 --> 之类的话，但往往是你要再翻一翻。还有的题flag写在响应头里，比如 flag: ctfhub{...}，或者写在不显眼的响应体注释里。
这类题的解法本身没有技术含量，但栽在上面的人相当多。原因很简单：在浏览器显示的页面上，你看到的是“渲染后的结果”，而不是“服务器返回的原始内容”。如果flag放在HTML注释里，浏览器不会显示出来，但源代码里能看到；如果flag放在响应头里，开发人员工具“网络”标签页里的响应头列表里能直接看到，但页面本身什么都没显示。
我比较推荐的做法是：每拿到一个Web题目，不管做没做出来，先把请求和响应从头到尾“通读”一遍。看请求头里有什么特殊的Cookie、特殊的字段；看响应头里有什么可疑的字段；看响应体源码里有没有注释、隐藏的div、外链的脚本。这个习惯一旦养成，后面的题目你会少走很多弯路。这道题看似送分，实际上是在帮你建立“三层查看”的意识：第一层看页面，第二层看源码，第三层看整个HTTP交互过程。
3.4 抓包：Cookie不是摆设
“抓包”这题很多教程里说得比较玄乎，其实拆开看就是考察你对Cookie的理解。题目页面打开之后，你可能看到一个“查看信息”或者“欢迎你的到来”之类的字样，然后提示你“请以管理员身份访问”。
此时你在开发者工具或者Burp里看一眼请求头，会发现请求头里带着 Cookie: admin=0 或者其他类似的字段。服务端逻辑很可能就是判断 admin 这个Cookie的值是不是1，如果是1就返回flag，否则就拒绝。你可以自己手动构造一个 Cookie: admin=1 的请求，发送过去看响应。在Burp Repeater里改起来特别快：把 Cookie: admin=0 改成 Cookie: admin=1，Send，看响应是否出现flag。
这里有一个新手容易犯的错：他们会在页面里找“登录”按钮或者“设置管理员”的入口，甚至去找数据库，然而这道题的考点就是“Cookie由客户端控制”这个浅显但关键的事实。服务器相信客户端传上来的Cookie，这本身就是一个典型的安全设计缺陷。当然真实环境中管理员权限不可能只靠一个 admin=1 的Cookie，但很多初中级Web系统里确实存在类似的不严谨判断。你理解了这一点，后面遇到“越权”类题目会轻松很多。
如果你用的是浏览器开发者工具，操作起来也别担心：在“网络”标签页里找到对当前接口的请求，右键选择“编辑并重发”，把Cookie值改掉再发送即可。部分浏览器这个功能藏得比较深，我觉得不如Burp直观。所以我在做这一题时基本都会开Burp，Cookie改起来顺手，而且能看到完整的响应包。
3.5 302跳转：重定向里的信息差
302跳转这道题，恶心程度不高，但坑人程度不低。正常逻辑是：你访问某个URL，服务器返回302状态码，同时在响应头里的 Location 字段告诉你“新地址在这里”，浏览器会自动跟着跳转过去。如果你只盯着浏览器地址栏看，很可能什么都没注意到。
CTFHub这一题的具体设计是：先访问 index.php，它返回302，让你跳转到另一个页面。如果你跟着跳转过去，最终看到的页面可能没有flag，或者flag藏在某个你忽略的地方。正确做法是：在Burp里关闭“跟随重定向”的功能，或者直接看历史拦截记录里的第一次302响应，把响应头里的 Location 字段和响应体都仔细看一遍。有些flag就放在302响应体里，但浏览器会自动跳到新地址，导致你根本没看到原响应。
再补充一种情况：有的题目不是让你看302本身，而是让你手动跳转到 Location 指定的位置，这次不跳就看不到flag，因为flag在跳转后的页面里。所以拿到302响应，先别急，分析三个方向：第一，原响应头里的 Location 指向哪；第二，原响应体里有没有内容；第三，跟踪跳转后，新请求和新响应里又有什么。这三个方向都观察一遍，就能把重定向层面的信息吃透。
这里还涉及浏览器和Burp之间的协作问题。Burp默认情况下会跟随重定向，但你可以通过改Proxy>Options里的Redirection设置，决定是Follow、不Follow，还是跟随但是记录原响应。我个人习惯改成“不自动跟随”，这样每次302都会停在我面前，我来判断要不要跳。虽然多一步操作，但信息量大多了。
3.6 伪造请求头：让服务器以为你是“内鬼”
这个类型的题在CTFHub里也出现过好几种变体，核心思路是让你通过构造特定的HTTP请求头来通过服务端校验。最经典的场景是：页面提示“只允许本地访问”或者“只允许内网访问”，你直接访问是普通用户页面，页面状态码可能还是200，但响应体里没有任何flag。真正的判断逻辑可能在服务端代码里检查了来源IP，而这个来源IP在Web层往往是从请求头里取的。
这里常见的可伪造字段有几个：X-Forwarded-For、X-Real-IP、X-Client-IP、Client-IP。很多开发者图省事，直接从这类请求头里取IP来用，而没有真正从TCP连接层获取。于是你只要在请求头里加上 X-Forwarded-For: 127.0.0.1 或者 X-Real-IP: 127.0.0.1，服务端就会误认为是本机访问，从而放行并返回flag。
实际操作中，有些平台对这几个字段都做了检测，所以不一定只是X-Forwarded-For一个字段的事。我的经验是逐个试：先试 X-Forwarded-For: 127.0.0.1，不行再试 X-Real-IP: 127.0.0.1，然后试 X-Client-IP、Client-IP，甚至四个都加上。有些时候服务端代码是这样写的：先找X-Forwarded-For，如果为空再找X-Real-IP，所以你把所有字段都带上，能提高命中率。改完请求，点Send，看响应里是否出现flag。
我还遇到过一个变体，需要伪造 Referer 字段。页面提示“请从Google进来”，那你就把请求头里的 Referer 改成 https://www.google.com 再发送。这一类题本质上都一样，都是在考你有没有意识到请求头是完全可以被客户端篡改的。浏览器出于安全策略会自动带某些头，但抓到包里你完全可以改成任何值，服务器如果盲目信任，就会产生问题。
4. 通关过程中最常见的五个坑
4.1 改完请求不知道去哪看响应
新手最容易卡在“我改完了请求，但响应在哪看”这个问题上。如果你在Burp的Repeater里改完请求点Send，响应框会直接显示响应内容，里面有状态行、响应头和响应体。有些人把这个和浏览器页面混在一起，结果在浏览器地址栏里刷新，看到的还是原页面，就以为自己的修改没生效。请记住：浏览器页面显示的内容和Burp里返回的原始响应，是两码事。你修改的是HTTP层的内容，必须在工具里看返回的信息。flag一般就在原始响应体或响应头里，根本不在渲染后的页面上。
4.2 Base64解码过于顺手，忽略了上下文
碰到Basic Auth的题目，很多人一看到 Authorization: Basic xxx 就条件反射去找个工具解码，解出来是 用户名:密码 的格式。这个思路没错，但别忽略一个前提：有时候题目故意把用户名和密码藏在页面的注释里，或者藏在响应头里面，你只顾着解Base64，解出来是一串乱码，反而耽误时间。正确的顺序是：先分析题目给的所有信息，再决定要不要解码。Base64只是编码，解码只是把数据还原出来，真正有价值的是你如何得知初始的用户名密码组合。
4.3 浏览器自动跟随重定向，导致天然丢失第一个响应
这一点我在前面已经强调过，但还是要单独拎出来说。浏览器处理302是自动的，所以你一旦在地址栏输入URL回车，你看到的永远是“最终页面”，中间那个302响应你是看不到的。如果在做题时遇到“页面怎么没反应”“直接跳到了另一个地址”这种情况，第一反应应该就是：回到Burp，把Redirection关掉，重新请求一次。不关掉跟随功能，你连真正的第一响应都看不到，自然也就找不到flag。
4.4 大小写和空格这类“低智商错误”
别笑，这个坑真的很常见。改请求方法时，有人把 CTFB 写成 CTFB 前面多了一个空格，或者把 /index.php 改成 /index.php 多了一个空格，服务端找不到路径，返回404，你就很慌。还有的题目要求精确大小写，比如 X-Forwarded-For 写成 x-forwarded-for，虽然在HTTP协议里请求头名称大小写不敏感，但某些后端框架在取值时可能是精确匹配的。所以在改请求包的时候，尽量保持和题目提示完全一致，不要自己发挥。实在不行直接复制题目给出的方法名或字段名。
4.5 浏览器缓存和代理叠加带来的混乱
有时候你在Burp里改了一万个参数，但浏览器那边显示“504”“连接失败”，仔细一看原来是之前代理设置错了，流量根本没走Burp。这种情况我遇到不止一次。解决办法很简单：做CTF题之前，先确认Burp的HTTP history里能看到你的请求记录。能看到，就说明流量正常经过代理；看不到，就是代理配置或者证书有问题。与其在题目上浪费时间，不如先把环境调试顺了再开打。
5. 通关之后：这套技能还能用在哪
5.1 后续CTFHub技能树里，你会反复用到这些操作
CTFHub在Web前置技能里安排了不止HTTP协议这一个模块，后面还有“Web工具”、“信息泄露”、“PHP特性”等若干关卡。等到你刷“信息泄露”的时候，你会发现各种 .git、.svn、备份文件泄露，本质上也是在和HTTP请求/响应打交道——你要从服务器返回的状态码、响应体内容去判断是否存在某个文件。到“命令注入”和“文件上传”模块，你要在Burp里构造带Payload的POST请求，手动设置 Content-Type，这些能力都是在HTTP协议这一关打下的底子。
而且我特意要说一下：HTTP协议相关的知识点，在后来的真题里会换个马甲反复出现。比如某些题目要求你“使用 TRACE 方法”来探测，或者让你判断“服务端是否信任了X-Forwarded-For”。这些在CTFHub基础模块里练过的操作，会让你在真实环境下快速定位到请求包里的关键字段。不要小看这些“基础题”，它们的设计就是让你形成肌肉记忆。
5.2 真实业务场景中的HTTP理解也很重要
如果不是为了打比赛，单纯做Web开发或者安全运维，这些HTTP知识同样用得上。很多前后端联调问题，排查到最后就是请求头或状态码的理解偏差：为什么Nginx返回了302？为什么接口报401？为什么服务器看到了不同的IP？如果你能从HTTP协议层面去思考，很多看似玄学的问题都能迎刃而解。CTFHub这一模块虽说只覆盖了很小的HTTP子集，但它建立的理解框架是通用的：请求方法、请求头、状态码、Cookie、重定向、认证，这些是Web世界里最基本也最核心的组成元素。
就我个人经验来看，刷完这套HTTP协议题目，最大的收获不是记住哪一题的flag，而是养成了一个习惯：拿到一个Web应用，先抓包看原始请求和响应，而不是先盯着页面瞎点。这个习惯在后续所有Web题目里都让我省了大量时间。如果你正准备刷CTFHub，建议从这一关老老实实起步，把每个请求、每个响应头都看明白，再往后走，你会发现整个技能树的脉络一下就清晰了。