判断一条请求是不是代理发出的，不能只看 IP 地址。公司网络、手机运营商出口、隐私工具和自动化程序都可能经过代理；反过来，攻击者也能使用普通家庭网络。流量攻击期间如何区分真实用户与代理请求，关键是把来源、行为和业务结果放在一起看，而不是见到代理特征就直接封禁。
新手可以先记住一点：单个信号只能提示风险，多个相互独立的异常同时出现，才更值得采取限制措施。
先看四类信号，而不是先查 IP
1. 请求节奏与路径是否像正常操作
观察同一会话在短时间内访问了哪些页面、请求间隔是否稳定，以及是否持续请求不存在的路径。正常浏览常有页面切换、静态资源加载和停顿；脚本则可能对单一接口重复请求，或按固定节奏遍历大量路径。不过，爬虫、自动化测试和页面预加载也会产生规律流量，不能仅凭“速度快”判定攻击。
2. 会话能否连续对应
查看 Cookie、登录状态、会话令牌及请求之间的关联。一个来源地址在短时间内切换大量账号、令牌反复失效，或同一会话呈现出互相矛盾的操作轨迹，风险较高。相反，未登录的新访客没有 Cookie 很常见；浏览器禁用 Cookie、清理数据或更换网络，也会造成会话中断。
3. 客户端信息是否前后一致
对照 User-Agent、Accept 等请求头、TLS 握手特征和页面行为。声明为常见浏览器，却缺少通常伴随页面访问的资源请求，或同一会话中的客户端特征频繁变化，值得进一步核对。请求头可以伪造，浏览器升级也会改变特征，因此这些信息只能用于风险评分，不能单独作为封禁依据。
4. 来源网络与业务结果
查看 IP 所属网络、地理位置变化和请求是否造成异常业务结果，例如登录失败集中增加、库存查询被反复触发。机房网络或公开代理出口可以作为线索，但企业出口、校园网络和移动网络也可能由许多人共享。地理位置数据库存在误差，移动用户的出口位置也未必等于用户所在地。
新手可照着做的排查顺序
选定观察窗口。先按分钟级时间段查看流量变化，并区分页面访问、静态资源和关键接口；不要把所有请求混成一个总数。
按会话和接口分组。对照请求频率、失败比例、账号数量、路径序列及响应状态码，找出异常集中出现的位置。只按单个 IP 分组，容易漏掉分散来源的自动化请求。
检查代理信任边界。如果服务前面有反向代理，确认应用只信任已配置的代理转发信息。未经验证的 X-Forwarded-For 等字段可由客户端自行填写，不应直接用来认定真实来源地址。
抽样核对业务轨迹。检查匿名访问、登录、表单提交等操作是否连贯；必要时结合应用日志核实结果。避免记录不必要的敏感信息，并按组织的数据保留要求处理日志。
先采取可回退的限制。对高频单接口优先设置短时、分路径的速率限制，或对可疑操作增加验证；保留观察和解除机制，再依据误拦情况调整规则。
代理请求和恶意请求不是同一回事
| 观察情况 | 更合适的判断 | 处置思路 |
|---|---|---|
| 来源属于共享出口，但访问节奏正常、会话连贯 | 代理或共享网络用户，证据不足以判定攻击 | 继续观察，避免整段封禁 |
| 同一来源高频触发单一接口，并伴随大量失败操作 | 自动化或滥用风险上升 | 针对接口限速，检查账号与会话关联 |
| 多个来源呈现相同请求序列，集中冲击关键业务 | 可能是分布式自动化流量 | 结合请求特征和业务影响实施分级防护 |
比较处置方式时，IP 封禁实施简单，但共享出口上的正常用户可能一起受影响；行为限速更贴近具体接口，规则需要持续校准；交互验证能增加自动化成本，却可能给无障碍用户或网络条件较差的访客带来不便。选择哪一种，应看被影响的资源、误拦成本和现有日志是否足以支撑判断。
把判断做成可复核的流程
每次调整规则，记录触发条件、影响接口、观察到的异常和回退方式。先从范围较窄的规则开始，比较调整前后的错误率、请求量和关键业务完成情况；如果正常访问也明显受阻，应及时收紧规则或撤销变更。流量攻击期间如何区分真实用户与代理请求，最终依赖的是可复核的多信号判断，而不是某个代理名单或单一技术特征。
常见问题
代理请求一定是攻击吗？
不是。代理常用于企业网络、隐私保护和网络转发，是否恶意要结合请求行为与业务影响判断。
只凭 IP 地址能识别真实用户吗？
通常不能。多人可能共用一个出口，同一个人也可能因网络切换而使用不同地址。
转发请求头能直接作为真实 IP 吗？
只有在可信代理正确清洗并传递相关字段、应用也限定信任来源时才可使用；否则字段可能被伪造。
新手应该先限制什么？
优先针对异常最集中的接口或操作设置可回退的速率限制，并持续检查误拦与业务结果。