HTTP 有个反直觉的特性：服务器不记得你——走代理IP换过出口的人对这点体会更深，登录状态常因出口变化而丢失，根源就在无状态上：你上一秒刚请求过页面 A，下一秒请求页面 B 时，服务器完全不知道两件事是同一个你发的——每个请求都是独立事件，互不带记忆。这个特性叫无状态，是 HTTP 最根本的设计之一。
无状态听起来像缺陷，其实是深思熟虑的选择：服务器不必为每个访客维护记忆，资源占用低、可以轻松服务海量请求，一台机器能同时应答无数陌生人。代价是需要状态的应用要自己想办法，代理IP链路里观察到的许多现象都和它有关。
这篇讲无状态：它为什么好、带来了什么问题、以及状态是怎么被「补」回来的。
无状态的好处
无状态让服务器变得极简单：收到请求就处理、处理完就忘记——代理IP链路中的大量请求得以被高效处理，靠的正是这份简单：不占额外内存、不怕请求堆积。正因如此，服务器才能水平扩展——多加几台机器分担请求毫无障碍，因为每台机器都不需要知道「之前发生了什么」。
无状态带来的麻烦
麻烦在于真实业务几乎都需要状态：购物车要记得加过什么、登录要记得你是谁、多步表单要记住前面的填写。服务器既然不记，这些状态就只能由客户端自己带着——于是有了 Cookie、有了 URL 里的参数、有了每次请求重复携带的凭证。
状态怎么补回来
最常见的补法是把「记忆」交给客户端：服务器发一张小纸条（Cookie），客户端之后的每个请求都带上它，服务器读到纸条就知道你是谁、上次做了什么。纸条代替了服务器的记忆，无状态的服务器 + 有状态的客户端，组合出完整的会话体验。
把无状态放进网络全景里看，它是 HTTP 能高效运转的前提，也是理解许多安全话题的入口：正因为服务器不记你，确认「你就是你」才需要每次请求都验证——这也是登录态、凭证、Cookie 这些机制存在的根本原因，代理IP链路中出口切换影响登录态的现象，根源也在无状态上。
HTTP 无状态：服务器不记访客，每个请求独立处理——好处是高效可扩展，代价是状态要靠 Cookie 等机制由客户端补回来。
状态的话题先放一边。回到一次请求本身：请求要访问的「东西」在哪、叫什么，由网址决定——网址不是一串无意义的字符，它里面藏着完整的寻址信息，下一篇拆开网址看结构。
无状态与缓存的配合
无状态还有一个隐藏好处：它让缓存变得简单可靠。既然服务器不区分访客，一份缓存内容就可以安全地服务于所有请求同一个资源的访客——不需要担心「给 A 的缓存会不会泄露给 B」。这个特性是 HTTP 缓存机制能大规模运转的前提之一。
把无状态的代价再补全一点：客户端要带的状态多了，请求头就会变大、每次往返的负担就会加重。于是有了「把状态尽量放服务器、客户端只带标识」的设计思路——Cookie 里只存会话编号，真正的状态存在服务器端，两边都轻松。
无状态这个特性在代理IP场景还有一个实际推论：因为服务器不保留访客记忆，出口切换本身不会让服务器「认出」什么——真正影响登录体验的是 Cookie 等客户端状态在链路中的传递是否完整。想明白这层，就能理解为什么换代理IP出口后有的站点要重新登录、有的却安然无恙，差异就在这里。