跨境支付、SaaS、出海电商、金融/加密业务的团队都会遇到用户IP是否来自制裁地区的问题，如果判断失误，损失一定的订单事小，出现合规事故后，解决合规事故的精力、损失的时机才是最难以挽回的东西。
其实这个问题很多相关业务的团队都会注意到，将有关制裁国家的IP封禁，但后来还是会出现合规问题。为什么？
其实这个问题源自于，合规问题并不是一个国家维度的问题，举个“栗子”： A国家中有①②③个城市，B国家有④⑤⑥个城市，当业务侧处理A、B国家的合规问题时，不是“IP解析 → A/C国家 ≠/＝ 制裁国 → 放行/拦截”就可以的，因为常常会出现以下情况 1）、A国家不制裁相关产品，但是③城市制止 2）、B国家个人放行，但加密、金融、云服务相关合规 所以单单是指判断国家相关，一定是不够的，所以基本做法应该是：
1、第一层：IP→国家/地区（基础过滤） 国家（Country）→一级行政区（Region/Province/State）→城市（City）
逻辑应该是-IP是否落在被明确制裁的地理区域内 Country=A Region=③ →命中制裁
这一步依赖的是IP地理定位数据的精细度，是否能做到“地区级别”，导入IP数据云IP地址查询定位库，足够用了。
2、第二层：反规避判断（非常容易被忽略） 制裁地区用户不会老老实实用本地IP，常见规避方式包括： V口N/Proxy、云厂商出口IP、Tor/匿口名网络、卫星网络
所以可以导入IP数据云的风险画像系统： 1）、IP是否为代口理/V口N/IDC/云IP 2）、IP ASN 是否异常 典型策略是： 制裁业务=地理命中+风险IP命中 → 拒绝或人工审核
！注意项
1）、只用免费IP查询接口 免费库： 地区精度不足（只到国家） 制裁地区更新滞后（版本落后） 免费≠可合规使用（有一些国家需要查看合规IP信息的来源，作为合规证明）
2）、规则写死在代码里 制裁名单是动态变化的（信息更替不及时，触发合规制裁）： 地区新增 限制升级 规则一定要可配置、可更新
