不误伤客户的地理封锁

# 不误伤客户的地理封锁

地理封锁常常在两个方向上出问题：拦不住真正想绕过限制的人，却挡住了正常出行的真实用户。好消息是，只要采用分层设计，这两类问题都可以大幅减少。

分清你为什么要拦截

• 授权。 内容版权通常按地域划分。你需要一个经得起解释的国家/地区判断，同时要把 VPN 出口视为未知位置，而不是简单当作出口节点所在国家。
• 制裁与合规。 这是法律义务，必须留下可审计的记录。每一次决策所依据的输入都要记录清楚。
• 滥用行为。 单靠国家/地区本身并不是强风险信号。真正起决定作用的，是流量分类和风险评分。

如果把这三类原因混在一起，六个月后很可能没人说得清当初为什么写下那条规则。

分层规则

if classification in (tor, hosting, vpn) -> location is untrusted, apply policy for unknown else if country in blocked_list -> deny with a clear message else if risk_score > threshold -> challenge, do not deny else -> allow

关键在于：把匿名化流量视为未知位置，而不是把它当作出口节点所在的国家/地区。否则，受限市场里的用户只要选一个允许访问地区的出口节点，就能轻松绕过限制。

像真人一样写错误提示

“该内容暂不支持在你所在地区访问”，再附上支持入口，用户的不满就有机会转化为一个可处理的工单。空白的 403 页面则很容易变成拒付和差评。

明确处理出行用户

一个使用已久的账号突然出现在另一个国家，通常是在度假或出差，而不是账号被盗。应当让账号历史的权重高于当前 IP：提升认证强度，而不是直接拒绝访问；同时记住这次验证结果，避免同一趟旅程每天都触发一次规则。

审计你做过的决定

保存最终决策以及产生该决策的输入（country、classification、risk score、rule id），而不是保存原始查询结果。这样既能形成审计轨迹，也便于后续调优阈值，同时不会不断堆积用户的位置数据。

每季度复查名单

封锁名单会过期。市场会开放，授权会变化，某次活动临时加上的规则也可能悄悄影响收入很多年。把复查写进日程表，定期清理。