印度是少有的一种情况：把「国家」当作地理定向的单位几乎毫无意义。28 个邦和 8 个中央直辖区在界面语言、商品品类、配送时效乃至可用的支付方式上都各不相同。一个没有绑定到具体邦的印度代理，只会让你看到一个任何本地买家都看不到的橱窗。下面梳理在这里真正影响结果的因素。
28 个邦与中央直辖区：定向单位不是国家
大多数本地电商在显示有货情况之前，都会先要求填写邮政编码。同一件商品，在某个编码下次日送达，在另一个编码下需要一周，在第三个编码下则根本不发货。区域卖家的商品品类，以及计入物流后的最终价格，同样绑定在这个编码上。
另一道鸿沟横在千万级大城市与中小城市之间。大都市圈有加急配送、更多可选卖家、更多支付方式，包括即时支付系统和货到付款。在较小的城市里，其中一部分选项干脆不提供。因此，用于此类核查的印度代理要按具体城市挑选，而不是按整个国家。
语言层：英语、印地语与二十余种地区语言
该国有两种全国性公务语言——英语和印地语——以及二十多种官方地区语言。大型平台会按地区语言输出界面：同一张商品卡片在不同的邦看起来并不一样，而搜索建议和广告素材的差异更大。
由此产生了一致性的要求。南部某邦的 IP，配上只含印地语的 Accept-Language 请求头，本身就是矛盾，网站在第一个请求里就会记录下来。合理的基准是印度英语区域设置：它对全国都是中性的，与任何地区都不冲突。只有当你要核查的正是某个地区的输出时，才替换成对应的地区语言。
半小时的时差：很少被核查，却读得很准的标记
印度时间相对 UTC 偏移五个半小时——不是整数个小时，而是在此之上再加三十分钟。全世界这类时区屈指可数，因此不一致会立刻显眼：浏览器系统时间若与该偏移对不上，再配上印度 IP，就暴露出这是一位非本地访客。第二个细节是该国不实行夏令时，偏移全年一致，因此任何时间差都找不到「季节性」的借口。
移动优先的国家：该选哪种 IP
这里的移动网络资费是全球最低之列，绝大部分流量来自手机。对本地平台来说，移动地址是统计上的常态，而桌面端的数据中心地址反而是例外。这改变了通常的类型排序，因此在选购印度代理时，类型的选择才是最主要的实务问题。
当你在意的只是「有一个印度出口」这一事实时，数据中心地址就够用：服务可用性、测速、调用公开 API。它价格便宜、按月购买，但按 ASN 会被读作服务器。ISP 通道在物理上位于数据中心，却登记在面向家庭用户的运营商名下，在地理库中被视为住宅地址。住宅通道是真实的家庭宽带连接，可精确到城市。移动通道则是蜂窝运营商的地址，其背后通过 NAT 聚集着数百名真实用户；对印度这个地区而言，这是最自然的选择。后两者的差异见移动代理与住宅代理的对比，自治系统的含义则见什么是 ASN。
流量消耗与结果核验
住宅通道和移动通道按 GB 计费，因此预算取决于任务量，而不是地址数量。参考数值：无媒体的纯文本页面约 0.3–1 MB，含图片的商品卡片约 2–5 MB。一百张卡片约需 0.3–0.5 GB，一千个纯文本页面大约 1 GB。真正省钱的不是买最便宜的流量，而是在自动化脚本里关闭图片与字体加载。
核验结果需要四个步骤，而不是一个。国家。邦与城市。ASN：家庭宽带运营商、蜂窝运营商，还是主机服务商。以及目标橱窗本身——价格是否以卢比显示，是否按你所需城市的印度邮政编码提供配送。最后一步比前三步更重要：地理库总是滞后于现实，而橱窗展示的正是真实访客所看到的内容。用于日常监控的指标汇总在如何检验代理质量一文中。
常见问题
能拿到印度某个具体邦或城市的 IP 吗？
住宅通道和移动通道支持精确到城市的定向，但范围越窄，池中可用的真实地址越少，拿到重复 IP 的概率越高。务实的做法是：先按国家定向，再核查实际分配到的地址属于哪个邦，只有在场景确实需要时才收窄条件。
用数据中心的印度代理做价格监控够吗？
对于公开 API 或没有地理过滤的页面——够用。可一旦橱窗要求填写邮政编码并按地区替换商品品类，服务器 ASN 就会开始遇到验证码。要定期采集商品卡片，就得用住宅通道或移动通道。
为什么印度地址有时会被判定成邻国？
地理库的更新存在延迟，部分地址段在转售之后的一段时间里仍登记在原持有者名下。地址信誉也有影响：风险评分偏高意味着已经有人用这个 IP 干过活。请在任务开始前就核查地址，而不是等到第一次被封之后。