流量安全
攻击分层
流量层的攻击按发生层次分为三类，防护手段也因此不同：
| 层次 | 典型攻击 | 原理 |
|---|---|---|
| 网络层（L3/L4） | SYN 泛洪、UDP/ICMP 泛洪、反射放大攻击、僵尸网络流量 | 用海量数据包耗尽带宽或连接表 |
| 会话层 | SSL/TLS 耗尽攻击 | 用大量握手消耗服务端计算资源 |
| 应用层（L7） | HTTP 泛洪（CC 攻击是其中针对动态接口的一类） | 用看似合法的请求耗尽源站处理能力 |
反射放大攻击的原理
攻击者伪造受害者的源 IP，向 DNS、NTP 等公共服务发送小请求；这些服务把大几十倍的响应发往"源地址"，受害者被放大后的流量冲垮——攻击者只花很小带宽就能制造巨大攻击流量。
两类攻击的应对逻辑完全不同：
拼的是流量规模，单个源站无法自保，必须依赖上游（云厂商或 CDN）的清洗能力，自己只需把流量引到清洗入口。CDN 边缘的缓存机制见 缓存。
请求与正常流量难以区分，必须分析请求内容才能识别，这是 WAF 和 Bot 管理存在的理由。
WAF 与规则集
WAF（Web 应用防火墙）检查 HTTP 请求内容，拦截注入类攻击（SQL 注入、XSS、路径穿越等）。规则分两类：
- 托管规则集：官方维护，覆盖通用漏洞，开箱即用
- 自定义规则：按 IP、国家、ASN（自治系统号，按同一路由策略运营的网络单元）、请求头等条件执行允许、阻止或质询动作，处理业务特有的防护需求
规则生效的前提是匹配可靠，因此代理在评估任何规则前会先做 URL 规范化——统一路径的大小写、编码和斜杠形式，防止用 /a/../b、%2e 这类路径变体绕过规则。
Bot 识别与质询
机器人流量治理的第一步是把 Bot 和真人区分开，常用识别手段：
- JS 探测：真实浏览器才会执行 JS，不执行的客户端可疑
- 浏览器指纹与请求头完整性检查：识别伪造客户端
疑似 Bot 的请求被发质询，质询分两档：
- 非交互式质询：在后台完成检测（如在浏览器环境里跑 JS），用户无感知、不影响体验
- 交互式质询：需要用户实际操作证明是真人，可靠性更高但打扰体验
通过后获得一段免检期，到期重新质询；攻击高峰期可以把全站切到"全员质询"模式应急。
对守规矩的 Bot 则按用途精细放行或拦截，常见三种各有不同诉求：
- 搜索引擎爬虫：抓取内容建索引、给站点带来流量，通常放行
- AI 内容抓取：拉取页面用于检索增强回答，用户直接得到答案不再访问站点，收益打折
- AI 训练爬虫：批量拉取内容训练模型，只消耗带宽不带来流量，许多站点选择拦截
robots.txt 声明只是软约束，对不遵守的爬虫要靠硬拦截。
诱捕不守规矩的爬虫
在页面注入对真人不可见的伪链接（nofollow 指向 AI 生成的内容），跟踪这些链接的即为不守规矩的爬虫——正常用户看不见、守规矩的爬虫不会抓，只有违规者会踩中。
速率限制与凭据防护
速率限制按来源维度控制请求频率，是防暴力破解和接口滥用的基础手段。单一维度各有盲区，通常组合使用：
| 维度 | 优点 | 盲区 |
|---|---|---|
| IP | 登录前即可生效 | NAT 出口后的合法用户被当作同一来源误伤 |
| 账号 | 精确到人 | 对登录前的探测无效 |
| API 密钥 | 精确到调用方 | 覆盖不了匿名接口 |
阈值参考正常用户的行为基线设定，超限后分梯度处理：
另需白名单放行健康检查和已知合作方，避免规则误伤自身。
针对登录接口，限流之外还有凭据防护。撞库攻击的密码来自已泄露的凭据库，对目标站点而言每个密码都"看似合法"，只靠频率限制防不住低速慢速的撞库。进阶做法是把限流与泄露凭据检查结合：把提交的密码与已知泄露库比对，命中的登录请求单独加强验证（强制二次验证或直接拒绝），而不是简单按 IP 一刀切。
哈希前缀比对
泄露凭据检查通常用哈希前缀查询：只上传密码哈希的前几位，在服务端返回的范围内比对，明文密码和完整哈希都不离开本地。
mTLS
mTLS 要求客户端也出示证书，双向验证身份。普通 TLS 只证明"服务端是谁"（TLS 握手与证书验证机制见 网络），mTLS 额外证明"客户端是谁"。它解决的信任问题是：API 密钥、Token 这类共享凭证可能泄露或被盗用，而客户端证书的私钥不出本机，身份无法被冒用。
机制上分三步：
- 签发：由服务端信任的 CA 为每个客户端签发证书
- 握手验证：服务端在 TLS 握手时校验客户端证书链，只放行可信客户端
- 生命周期管理：证书分发、轮换、吊销都由这套 CA 体系统一管理
服务网格（如 Istio）的 mTLS 之所以能落地，正是因为它把证书签发与轮换自动化了。
选用 mTLS 要权衡管理成本
客户端证书需要逐台安装导入且有有效期，管理成本高，面向浏览器普通用户不现实；适合 API 对接、内部服务等必须严格限定调用方的场景，浏览器场景下一般只用于企业内网准入。
信息泄露与头部防护
防护不只是拦截，也包括少暴露：
- 移除 X-Powered-By 这类标识源站技术栈的响应头，减少攻击者的情报。
- 添加安全响应头（CSP、XSS 防护等），在浏览器侧建立第二道防线。
- 邮箱地址混淆：页面中的邮箱对爬虫不可见、对人不影响，防批量采集。
- 热链接保护：校验 Referer 阻止外部站点直接引用本站资源，防盗链。
请求处理管线
代理对每个请求按固定顺序处理，理解这个顺序才能正确预判规则行为。其中缓存环节的机制见 缓存：
例如重写发生在访问控制之前，意味着访问控制匹配的是重写后的路径。
隐私访问
有些访问者不希望"谁访问了哪个站点"被观测（如监控、审查环境），站点也可能不希望暴露自己的真实服务器位置。洋葱路由（Tor）正是为此设计：流量经随机选择的多跳代理链中转，每一跳只知道上一跳和下一跳，无法掌握完整路径，从而隐藏通信双方的真实位置。
机制要点：
- 洋葱加密：请求出发前被层层加密，每个中继只解开属于自己的那一层——像剥洋葱一样，任何单个中继都看不到明文和完整路径
- 隐藏服务入口：站点可以额外提供一个 .onion 地址，流量全程走 Tor 网络进入站点，站点自身的真实 IP 与位置同样匿名
对站点而言这是多一种隐私友好的访问渠道，代价是：流量统一经中继进入，客户端指纹难以验证，前面 Bot 识别里的 JS 探测、指纹检查等手段对这类流量基本失效，只能放宽或单独制定策略。