代理 IP 不等于恶意用户：注册与登录风控中的 IP 情报分层设计

一、命中代理之后，要不要拦截？ 假设一个登录请求通过了密码校验，来源 IP 命中代理标签。系统据此拒绝登录，理由看起来很充分，但还有几个问题没有回答。 用户是否一直通过这个企业出口办公？这次访问与历史设备、会话是否一致？代理标签是在什么时候观测到的？当前请求有没有异常行为？ 如果这些信息都没看过，封禁依据就只有网络出口的一个属性。 IP 标签对风控有用，但它描述的对象与业务要判断的对象并不完全一致。标签通常落在 IP 上，处置却落在账号、会话或请求上。一个公网 IP 后面可能有多位用户，同一个用户也可能在移动网络、家庭宽带和企业网络之间切换。 反过来，未命中代理或风险标签，也不能证明请求安全。检测可能存在覆盖缺口，攻击者还可能使用此前没有风险记录的地址。 本文给出一套设计思路。文中的场景与规则均为示意，不代表客户案例或产品实测结果，也不提供可以直接套用到所有业务的风险阈值。 二、把网络属性、风险情报与业务行为分开 接入 IP 数据时，容易出现的一个问题是把不同含义的字段都折算成分数，再直接相加。这样虽然容易实现，却可能重复计算同一类证据，也很难解释分数为什么变高。 更稳妥的做法是先区分信息来源。 网络属性回答访问来自什么环境。 家庭宽带、移动网络、企业专线、数据中心，以及运营商、ASN 等信息，可以帮助系统理解访问背景。企业出口出现多个账号并不意外，不能沿用单个家庭用户的账号数量阈值。家庭宽带也不能作为安全白名单，住宅网络同样可能承载自动化访问。 风险情报回答该地址有哪些已知线索。 代理类型、历史风险标签、风险评分等可以提高调查优先级，但需要保留来源、时间和字段定义。风险评分若没有经过概率校准，就不能解释成当前用户作恶的概率。 业务行为回答当前请求正在做什么。 注册流程是否异常重复，登录失败是否集中发生，是否出现跨账号的相似操作，会话是否延续了正常使用习惯，这些信息需要业务自身提供。 三类信息应当组合使用。例如，代理标签单独出现时，证据不足；若又出现批量注册行为，并伴随验证异常，就有理由提高验证强度。即便如此，也应记录各项证据，避免把同源、强相关的标签当作多个独立风险重复加分。 注册与登录还要分别处理。注册没有成熟的账号历史，需要更多依靠流程行为；登录可以参考既有账号与会话信息，但密码正确、设备熟悉都不能单独排除账号被盗。 三、接入 IP数据要先了解返回字段有哪些 注册与登录场景可以使用以下几类数据。 IP代理识别提供是否代理、代理类型及代理时间等信息，公开类型包括 tor、vpn、proxy、relay。 IP应用场景提供运营商、ASN 和网络场景信息，包括家庭宽带、移动网络、企业专线、数据中心等类型。 IP风险画像提供风险等级、风险评分、风险标签，以及秒拨概率、真人概率等参考特征。 这些产品用于补充网络侧信息。账号历史、会话连续性和当前行为仍由业务系统采集，最终处置由业务策略决定。 建议用适配层将供应商响应整理为内部对象。 请求上下文 event_time 业务事件发生时间 client_ip 经可信代理链解析的客户端 IP account_ref 业务内部脱敏账号标识 scene register / login 网络情报 lookup_status ok / timeout / error proxy_status detected / not_detected / unknown network_type 已映射的网络场景或 unknown risk_labels 保留来源的风险标签 observed_at 来源明确提供的观测时间，可为空 queried_at 本次查询时间 data_version 来源可提供时记录 决策记录 policy_version 规则版本 reason_codes 命中依据 action 处置动作 expires_at 临时处置的到期时间 字段设计中， not_detected 与 unknown 必须区分。前者表示本次查询没有检出，后者表示缺失、失败或无法判断。两者都不应被翻译成「已确认安全」。 风险画像中的真人概率、秒拨概率也应保留原始含义。不能据此宣称已经验证当前用户的身份，或确定当前 IP 正由黑产控制。 取对客户端 IP，比多接几个标签更重要 如果业务经过 CDN、负载均衡或反向代理，应用直接看到的可能是中间节点地址。读取转发头时，需要依据已配置的可信代理链解析，不能无条件采用客户端传入的 X-Forwarded-For 首项。 对非可信来源提交的转发信息，应按入口策略忽略或拒绝。解析完成后，再处理 IPv4、IPv6 的表示规范、无效地址及地址类别。设备关联标识也需要明确来源与可信度，不能把任意客户端字符串当成可靠设备身份。否则，后面的风险模型可能一直在评估错误的地址。 四、给情报加上时间边界 动态地址分配和共享出口，使历史风险标签很难永久对应某个用户。某地址过去出现过异常，不足以说明当前使用它的请求同样异常。 工程上至少要区分三个时间概念。 事件发生时间属于业务日志；情报观测时间属于数据来源；查询时间只是系统何时拿到了结果。刚刚查询到的数据，可能仍然来自较早的观测。API 响应速度快，也不代表情报更新得快。 对于有明确观测时间的字段，可以按业务容忍度配置有效期；对于没有观测时间的字段，应标记时效未知，降低其在强处置中的权重。不能为了让计算流程完整，就用查询时间补成观测时间。 不同字段也未必适用同一个缓存周期。网络归属信息和短期风险信号的变化速度可能不同，缓存需要结合供应商更新机制与业务验证结果设置。 地址关联统计同样需要时间窗口。「这个 IP 历史上登录过多少账号」与「这个 IP 在当前窗口内尝试了多少账号」不是同一个特征。若将长期累计账号数用于即时封禁，共享网络会持续累积风险。 五、把命中结果映射到不同处置 一个可用的策略不应只有放行与封禁两个出口。更细的动作能让系统在证据不足时继续收集信息，也能减少一次判断失误的影响。 可以先设计四类处置。 保持现有认证并记录。 只有单个网络标签，当前行为没有明显异常时，不额外施加 IP 驱动的阻断。这里的「保持」不表示跳过密码、验证码或业务原有控制。 增加验证。 网络线索与部分行为异常同时出现时，按场景要求用户完成额外验证。登录可使用已绑定的认证因素；注册可增加流程验证和资源限制。验证本身也需要控制重试与发送成本。 限频并调查。 出现持续异常或关联活动时，优先作用于有证据支持的会话、设备关联对象或业务操作。确需出口级限频时，应单独评估共享网络影响，避免把一个可疑请求扩大为整个出口的永久限制。 临时阻断或限制敏感操作。 存在足够强的独立业务证据时执行，同时记录依据、到期时间和恢复条件。不能只因命中代理标签就永久封禁账号。 下面的伪代码说明判断顺序，省略了特征构造、具体阈值与认证细节。它不能直接替代生产规则。 运行基础认证与已有业务安全规则 若业务侧存在已核实的强风险证据 执行有时限的限制，保存依据与复核入口 否则若情报查询失败、过期或关键字段缺失 进入降级分支 根据操作敏感度保留本地规则或增加验证 否则若有效网络风险线索与业务异常同时存在 增加验证，必要时限频并进入调查 否则若仅有网络风险线索 记录