你可能会说：
- “前端和后端放在两个平台上，怎么让它们用同一个域名？”
- “AI 写了一段转发脚本，说能解决跨域，它到底做了什么？”
它是什么
访客的请求先到反向代理，代理按路径等规则把请求转给后面的某个服务，再把结果交还给访客。对访客来说，自始至终只和一个地址打交道。
常见用途：让前端和后端共用一个域名（/api/ 开头的交给后端，其余交给静态页面）；在后端前面统一处理 HTTPS、缓存和限流；后端搬了家，只改代理规则，不改域名。
代理规则写漏了，请求就会落到别处去，而且常常看起来是成功的：本该由后端回答的请求，被前端的兜底页面接住，返回一张网页和 200。
打个比方
像写字楼的前台：访客只认识前台，前台看一眼来意，把快递送上三楼、把面试的人领到五楼。访客不需要知道楼里怎么布局。
在这个网站里
兄弟项目 E2E Review 的前端放在 Cloudflare Pages，一段 Worker 脚本把 /api/ 开头的请求转给 Railway 上的后端。规则只写了 /api/，于是健康检查地址 /healthz 落进了前端的兜底页面，返回的是一张网页（第 5 课）。
容易搞混的地方
常见误解
反向代理就是翻墙用的那种代理
正确理解
那是替访客出门办事的正向代理。反向代理站在服务器这边，替服务器接待访客。
你可以这样告诉 AI
复制下面这段，贴给你的 AI
列出这个转发脚本的全部规则：哪些路径转给后端、转发时改了哪些请求头、后端超时或出错时返回什么。再用 curl 分别请求一个接口地址、一个页面地址和健康检查地址，确认每个请求都到了该去的地方。
接下来去哪
先知道
接着看
- 健康检查——一个专门给程序访问的地址，用来回答"服务现在还好吗"。
在这些课里出现
相关的真实事故