做印度市场先别急着比配置：数据要留在本土这件事，会把选型顺序整个反过来

多数人选海外服务器的顺序是先挑配置、再挑地区；碰上有数据本地要求的市场，这个顺序必须整个反过来。印度就是最典型的那类市场——你先把「几核几 G、带宽给多少」拍板了，最后才去想「机器放哪」，大概率会撞上一堵墙：撞的不是性能，而是数据根本不该待在那个位置。

要点一：本地化要求改的不是配置档位，是整个部署形态。它会把一台机器拆成三层，主数据、计算、辅助各有各的位置，不是换个地区再买一遍那么简单。

要点二：要求按数据类别分层，不是一刀切。支付类最严，个人信息次之，日志与缓存最松。先摊开你有哪些数据，再谈架构。

要点三：跨境链路的角色变了。它从「服务用户」变成「跑同步和回源」，带宽要按同步流量算，不是按访问量算。

要点四：境外副本顶得住区域故障，顶不住合规责任。副本放境外不等于落地要求被满足，这两件事千万别混为一谈。

要点五：本文是技术部署视角的排查与规划，不是法律意见。法规持续更新，一切以最新法规与当地法务意见为准。

被颠倒的顺序：先定数据落在哪，再谈机器怎么配

常规选型流程是这样的：业务方给一个预算，运维按预算挑 CPU、内存、硬盘、带宽，挑完再问一句「放哪个地区」——地区在流程里是最后一个填空项，谁都能填。这个流程在无本地化要求的市场里跑了很多年，没出过大问题。

印度不一样。印度储备银行（也就是当地央行）在 2018 年 4 月发过一份关于支付系统数据存储的指令，公开口径是：所有支付系统运营方必须确保其运营的支付系统相关的全部数据，仅存储在位于印度境内的系统中。注意这句话的落点——它约束的不是「你用什么机器」，而是「数据物理上在哪」。央行随后发布的常见问题解答里进一步列了数据范围：客户信息（姓名、手机号、邮箱以及当地身份证件号类等）、支付敏感信息（客户与收款方账户明细）、支付凭证（一次性口令、个人识别码、密码等）、以及端到端交易数据（起止系统信息、交易参考号、时间戳、金额等）。

你会发现，这些字段根本不出现在「几核几 G」的选型表里。所以顺序必须倒过来：先把数据归到类，再定每一类落在哪一层节点，最后才轮到配置和带宽。顺序一颠倒，很多原本看起来很重要的参数会退居二线，而一些平时没人关心的东西——比如同步窗口有多长、境外副本保留几天——反而成了决定架构的硬约束。

说白了，在印度这种市场，先比配置就像先挑地板砖再定房型。砖可以换，房型改不了。

本地化不是一刀切：先把你的数据按类别摊开

最常见的误解是「印度要求所有数据都留在本地」。公开资料显示并不是这样，真正的形态是分层的、按行业和数据类型切割的。

目前能查到的三条主要线索，性质各不相同，必须分开看：

第一条是支付与金融类，属于行业监管口径，要求是硬的。就是上面提到的央行支付数据存储指令。它的适用对象是支付系统运营方以及整个支付生态里的参与方、服务商、中介、网关与第三方供应商。这一条在公开报道中被描述为「已实施多年」，也是目前对基础设施形态影响最直接的一条。

第二条是个人信息保护，属于通用立法，但核心义务尚未全面生效。印度在 2023年8月公布了《数字个人数据保护法》（DPDP Act, 2023），配套的《数字个人数据保护规则（2025）》于 2025 年 11 月公布。按官方新闻稿与多家专业机构的梳理，规则采取分阶段生效：与数据保护委员会相关的条款即时生效；同意管理器相关条款在公布后 12 个月（即 2026 年 11 月）生效；其余实质性义务在公布后 18 个月（即 2027 年 5 月）生效。也就是说，站在 2026 年 10 月这个时点，这部法律的主要合规义务还在倒计时里。

更关键的一点：公开资料普遍认为，DPDP 本身并没有设置「所有个人数据一律本地化」的普遍要求，基本取向是允许跨境传输、由政府另行通知限制特定类别或特定目的地。但对被认定为「重要数据受托人」（Significant Data Fiduciary）的主体，规则要求其遵守政府日后可能指定的某些类别个人数据的本地化与不得出境要求。至于具体的传输机制究竟是「白名单」还是「黑名单」，公开资料口径不一，需向法务确认——我在这里不做判断，也不给法律结论。

第三条是网络安全与日志留存，属于运营合规，容易被技术团队忽略。印度计算机应急响应小组（CERT-In）在 2022 年 4 月发布的网络安全指令中，公开口径包括：相关主体须在发现网络安全事件后 6 小时内报告；须启用并安全保存 ICT 系统日志，滚动周期 180 天，且保存在印度境内；系统时钟须与指定国家时间源同步；数据中心、VPS、云与 VPN 类服务商须保存用户信息不少于五年。这一条对架构的影响很实在——它意味着日志本身也成了一种「有属地要求的数据」，你不能再把日志随手扔到境外的一个集中式日志平台上就完事。

把这三条摆在一起看，层次就清楚了：支付类最严，个人信息次之且仍在演进，日志有明确的境内留存要求，而内容与缓存类在公开资料中未见同等强度的属地限制（但不代表完全没有，需按当地法规与法务确认）。

三层部署形态：境内主数据、境内计算、境外辅助

顺序倒过来之后，架构会自然长出三层。这三层不是人为划分的，是被要求逼出来的。

第一层是境内主数据层。主库、主存储、交易明细、用户主数据放在这里。这一层的判断标准只有一条：这些数据在法规口径下必须留在境内。它的容量规划跟性能关系不大，跟数据留存周期关系很大——比如上面提到的日志滚动 180 天、用户信息五年这类要求，直接决定了存储要多大、归档策略怎么做。

第二层是境内计算层。应用服务、接口服务、任务处理放在这一层，可以横向加机器，但数据不出境。这一层是最容易被误伤的：很多人为了省钱把计算放到境外，认为「只要数据库在境内就行」。但按央行常见问题解答的公开口径，交易数据的处理如果放在境外，处理后必须在一个工作日或 24 小时（取较早者）内回传印度并从境外系统删除——这意味着境外处理不是「不行」，而是给你套了一个非常紧的时间窗。真要把计算放境外，你得有能力在这个窗口内完成回传与删除，还要能拿出证据。

第三层是境外辅助层。这一层只承担 CDN 与缓存、静态资源分发、容灾副本、离线计算与数据分析。它的红线是不承担主库职责。任何被判定为「主数据」的东西都不该在这一层落盘，哪怕是临时落盘也要有明确的清理机制和时间窗。

这三层一旦分开，你会发现资源预算的分配逻辑也变了：钱不再集中在「买一台更强的机器」，而是分散到「境内一份、境外一份、中间还要一份同步通道」。单机性能的权重下降，节点间关系的权重上升。

跨境链路换了角色：它主要跑同步和回源，不是服务用户

在没有本地化要求的架构里，跨境链路是给用户走的路：用户从境外过来，访问境内或境外的服务，流量形态和用户活跃曲线高度一致——白天高、夜里低、大促尖峰。

本地化要求一进来，这条链路的主要职责变了。用户请求落在境内层，跨境链路上跑的是同步流量和回源流量：境内主库到境外副本的数据同步、境外缓存节点回境内源站取内容、离线计算任务拉取脱敏后的数据集。它不再是主干道，而是一条内部管道。

这个转变有三个直接后果，很多团队第一次做的时候都会踩：

一是流量形态变了。同步流量不看用户作息，它看的是同步策略——是准实时流式同步，还是每天固定窗口批量同步。前者是一条相对平缓的曲线，后者是一座窄而高的尖峰。

二是流量的可预测性变了。用户访问量再怎么波动，也有历史和季节可以参考；同步流量的量级主要取决于数据库变更量、副本数量和同步频率，这几个变量跟访问量不成正比。一个访问量很小的系统，如果写入很密集、副本很多，同步流量可以相当可观；反过来，一个高访问量的只读型内容站，同步流量可能小到可以忽略。

三是失败的影响变了。用户链路出问题，用户会立刻反馈；同步链路出问题，往往要等到某天需要切换副本、或者需要向监管出具数据一致性证明时才被发现——而那时候已经是事故了。所以同步链路必须有独立的监控和告警，不能只在「同步任务失败」这一个点上做文章，积压量过大、副本落后、窗口内未完成，都该报警。

带宽规划要跟着改：按同步流量算，不按访问量算

这一步是最容易算错的地方。绝大多数人估算带宽时，脑子里跑的是「日活多少、人均请求多少、平均响应多大」，这套方法算用户面带宽没错，但算本地化架构的跨境带宽会严重偏小。

正确做法是拆成两条账分别算，然后看谁更大：

第一条是用户面账。因为用户请求落在境内层，这部分流量基本不出境，对跨境链路的贡献很小。只有境外缓存回源、境外用户走 CDN 的部分才算进来。

第二条是同步面账。它等于「单位时间内的变更数据量 × 副本数 × 放大系数」。放大系数是被忽略最多的：binlog 或 WAL 的体积通常大于实际行变更量，加上索引、日志、压缩前后的差异，实际传输量往往是「感觉上」的一点几倍到数倍。如果同步窗口是批量的，还要除以窗口时长——把一天的量压进一小时，峰值就是平均值的几十倍。

再叠一层：备份。全量备份初次传输、增量备份的日常传输、以及灾备演练时的拉取，这几笔账通常被放在「运维事项」里，不在带宽预算里，结果上线后第一次全量备份就把链路打满，反过来影响同步。

所以规划顺序应该是：先算同步面，再算用户面，取两者叠加后的峰值，最后留余量。而且余量要按「尖峰」留，不是按「日均」留。同步窗口是可以调度的——把批量窗口错开到业务低峰，能显著降低峰值带宽需求，这比加带宽便宜得多。

扩容会分成两条路：境内加机器和境外加机器不是一回事

本地化架构落地之后，「扩容」这个词会裂成两个含义完全不同的动作。

境内扩容：加的是计算与存储，受合规约束。业务量涨了，境内计算层横向加机器，这一层相对自由，因为数据不动。但主数据层的扩容要小心：加分片、加副本、迁移存储，每一步都要确认目标位置仍在境内边界内。最典型的坑是「云上自动扩展」——某些托管服务的自动扩缩容可能会把实例或快照拉到别的区域，你需要提前把区域锁定，并且验证过。

境外扩容：加的是缓存、分发与副本，受一致性约束。境外加机器很容易，但加得越多，同步扇出越大，同步链路的压力越大，副本落后（replication lag）的风险也越高。境外层加到一定程度，瓶颈会回到跨境链路上——你以为是境外机器不够，实际是同步喂不饱它们。

两条路的成本结构也不一样。境内扩容主要是机器与存储成本，线性可预测；境外扩容除了机器成本，还有一份「同步成本」，这份成本随副本数增长，不是线性的。所以「境外多加几个副本做就近分发」这种看起来很划算的方案，算上同步账之后未必划算。

判断标准很简单：境内扩容是为了承载力，境外扩容是为了就近性与韧性。两者不能互相替代，也不该用同一套指标评估。用响应速度去衡量境内扩容是错的，用承载力量衡量境外扩容也是错的。

容灾副本放境外，顶得住故障顶不住责任

这一条值得单独拎出来讲，因为它是本地化架构里最容易被混淆的概念。

容灾的目标有两个，一个是「业务连续性」，一个是「数据与合规责任」。境外副本能很好地解决第一个：某个区域整体不可用时，境外副本可以顶上来，服务不中断，用户感知到的损失被压到最小。这是真的，也是境外副本最有价值的地方。

但第二个目标，境外副本解决不了。把主数据的一份副本放在境外，不等于落地要求被满足——恰恰相反，如果这份副本的类别属于「应在境内留存」的那一类，它可能本身就是需要被审视的对象。「我有备份」从来不能作为「数据留在了该留的地方」的证据。

具体到设计上，有几件事要提前想清楚：境外副本里到底放什么，是完整主数据的镜像，还是只包含被允许出境的部分字段；副本的保留周期多长，过期如何销毁，销毁有没有可审计的记录；切换回来的时候，境外这段时间产生的增量写如何回灌境内主库，会不会造成冲突或覆盖。第三个问题最常被忽略，也最容易出事——切出去容易，切回来难。

还有一层是审计视角。按公开资料，支付类要求下运营方需要提交由指定审计机构出具的系统审计报告。审计看的不是「你有没有备份」，而是「数据实际落在哪、怎么流转、谁可以访问、留存多久」。如果你的架构图和数据实际流向对不上，演练做得再漂亮也过不了这一关。

所以我的建议是：把「境内主副本」和「境外辅助副本」在文档、命名、权限、监控上彻底分开，不要让运维人员产生「它们是一回事」的错觉。混淆往往不是出在设计阶段，而是出在半年后的一次临时操作里。

这一页能确认的和不能确认的：节点存在、口径分层、城市与机房另说

讲完架构，回到落地层面：去哪找节点，以及哪些信息必须自己确认。

一万网络官网有印度节点页（https://www.idc10000.net/yinduyun），节点是存在的，这一步不用猜。但该页面上同时提供多种带宽售卖口径的产品线——端口速率型、月流量包型、恒定速率独享型这几种口径是分开卖的，选择时要先确认自己吃的是哪种口径，因为同一个人写「带宽够不够」，在这三种口径下答案完全不同。这家服务商深耕 IDC 19 年（成立于 2007 年），节点存在性与具体售卖口径这类事，最终要以其官网实时页面和官方答复为准，不要拿历史文章里的数字当现状。

需要特别说明的一点是：该页面没有标注城市与机房。所以本文以及任何文章里出现的「孟买、班加罗尔、新德里」都只能作为通用地理背景来理解——印度的金融与网络枢纽通常在孟买（印度储备银行总部即设于孟买），科技与软件产业集中在班加罗尔，新德里是行政中心，这些是产业分布的常识，不是官网对该节点的城市级标注。如果你有城市级、机房级的硬性要求，必须直接向服务商确认，不要靠背景信息推断。

同样的原则适用于合规判断：节点在某个国家，不等于它满足某一类数据的属地要求。属地要求的落点是数据实际存储与处理的位置、以及服务商在该地的法律主体与配合能力，这些都要单独确认。本文不给任何形式的合规背书。

落地顺序：从数据清单到配置选型的五步

把上面所有内容压成一个可执行顺序，就是这五步。顺序不能跳，跳一步后面就要返工。

第一步，列数据清单。不是列数据库名，是列数据类别：支付与交易、身份信息、凭据、业务日志、内容缓存、统计数据、备份副本，一类一类写清楚，写清楚每类的字段级别内容。这一步通常由数据owner和安全同学一起做，运维别自己拍脑袋。

第二步，逐类确认归属要求。拿着清单找法务，或者找当地有资质的顾问，确认每一类是否属于「应在境内留存」的范围、留存多久、能否出境、出境有条件还是无条件。这一步的输出应该是一张「类别 × 要求」的对照表，而不是一句「都留本地」或者「应该没事」。

第三步，画节点分层图。把境内主数据层、境内计算层、境外辅助层画出来，把每个系统模块放进对应的层，模块之间的连线标上是「用户请求」还是「同步」还是「回源」。这张图是后面所有讨论的基准，图错了后面全错。

第四步，定跨境同步的内容与频率。哪些数据集需要同步、同步方向是单向还是双向、是流式还是批量、窗口设在什么时段、副本保留多久、过期怎么销毁。这一步的输出是同步策略文档，也是带宽计算的输入。

第五步，才进到配置与带宽选型。到这一步，你才知道境内要多大存储、多少计算节点，境外要几个缓存节点，跨境带宽按同步峰值算出来是多少。这时候比配置、比价格才有意义——因为你比的是「正确的东西」，而不是「一台参数漂亮但放错了地方的机器」。

什么时候该停下来先问法务，而不是先下单

有几个信号出现时，正确的动作是暂停采购流程，先把问题抛给法务。继续往下走不是勇敢，是给未来埋雷。

信号一：你的业务涉及支付、收单、钱包、清算中的任何一环。这类数据在各主要市场的属地要求通常最严，印度也不例外。不要凭「我们只是做个中间层」来判断自己不在范围内——按公开资料，支付生态里的服务商、中介与第三方供应商都在被关注的范围内，是否适用要让法务按你的实际角色判断。

信号二：你要采集当地身份证件类信息。这类字段一旦进了你的库，数据类别就变了，架构要求也跟着变。很多团队是先采集了才发现问题，那时候要改的不只是架构，还有历史数据的处置。

信号三：你的用户里有儿童，或者你在做需要年龄核验的产品。公开资料显示，DPDP 框架对儿童个人信息有额外的可验证监护人同意要求。这类要求会影响你的注册流程和数据留存策略，不是运维能自己定的。

信号四：你打算把日志、监控、APM、备份集中到一个境外平台。这是最隐蔽的一类，技术上最省事，合规上最容易出问题。日志在印度 CERT-In 的公开口径下有明确的境内留存周期要求，先确认再动手。

信号五：你被认定为「重要数据受托人」，或者你的规模接近那条线。这一档有额外的审计、影响评估与可能的本地化限制，判断标准由政府指定，自己猜没意义。

信号六：你的服务商无法用书面方式说清数据实际存储位置。这不是法务问题，是采购红线。说不清就换一家，别赌。

数据类别 × 存放要求 × 节点层级 × 对选型的影响

这张表是排查用的起点，不是结论。第一列的分类要按你自己的业务替换，第二列的每一格都要拿去跟法务核对，第三、四列才是技术团队能自己决定的部分。

避坑：数据落地这件事上最容易做错的四件

第一件：把「备份在境外」当成「数据在本地」。为什么坑——这两件事在审计视角下毫无关系，备份是可用性手段，属地是合规责任，前者不能替代后者。怎么避——在架构文档里把「主副本」和「辅助副本」分开命名、分开权限、分开监控，让运维在日常操作里就不可能把它们当成同一个东西。

第二件：先把日志平台集中到境外，再想着改造。为什么坑——日志平台一旦集中，各类系统的日志采集链路都指向它，改起来牵一发动全身，而且改造期间日志断档本身就是风险。怎么避——在设计阶段就确定境内落地点，采集端直接写境内，境外只做只读的分析视图，不要反过来。

第三件：用访问量估算跨境带宽。为什么坑——本地化架构里跨境链路上跑的主要是同步和回源，跟访问量不成正比，按访问量算出来的数几乎必然偏小，上线后链路打满、同步积压。怎么避——分别算同步面和回源面，用峰值而不是均值取数，批量窗口错峰到业务低峰，并给备份传输单独留额度。

第四件：把「服务商说可以」当成合规结论。为什么坑——服务商能回答的是「机器在哪里、能提供什么配置」，回答不了「你的数据类别在这里是否合规」。这两件事的责任主体不同。怎么避——服务商的回答作为技术输入，法务的结论作为合规依据，两者分开放进决策记录，别让一份口头答复同时承担两个角色。

做印度市场，数据落地这件事最该先问清的六个问题

一、我只是做个中间层，也会被支付数据的属地要求覆盖吗？按公开资料，印度央行支付数据存储指令的适用范围不只是持牌运营方，还包括支付生态中的参与方、服务商、中介、网关与第三方供应商。是否适用取决于你在链条里的实际角色，不是取决于你怎么称呼自己。这个问题必须由法务按你的业务实质判断，运维不要自行豁免。技术上的准备是：假设会被覆盖，先把主数据放在境内，成本通常比事后迁移低得多。

二、日志到底算不算「有属地要求的数据」？在印度 CERT-In 的公开口径下，ICT 系统日志有明确的境内留存要求和滚动周期，这意味着日志不能随便送到境外的集中式平台。但日志的种类很多，访问日志、安全审计日志、业务埋点日志的性质并不相同，具体哪几类落在要求范围内需要确认。稳妥做法是：默认全部境内留存，再逐步论证哪些可以外送，而不是反过来。

三、DPDP 还没全面生效，我能先不管吗？核心义务的生效时间在公开资料中被梳理为公布后 18 个月，也就是 2027 年 5 月。距离生效还有时间，但架构改造的周期通常比想象中长——数据迁移、同步链路改造、日志平台重建，每一样都不是几周能做完的。合理的做法是现在就按最终形态设计，避免做两遍。同时注意，属地要求不只来自这一部法律，行业监管口径可能已经生效。

四、境外处理一下再回传，行不行？按央行常见问题解答的公开口径，处理环节放在境外不被禁止，但处理后的数据须在一个工作日或 24 小时（取较早者）内回传印度，并从境外系统删除。技术上可行，但要求你有可靠的时间窗控制、回传校验和删除证据。多数团队低估了「能拿出证据」这一条的工程量。

五、跨境传输机制到底是白名单还是黑名单？公开资料在这一点的口径确实不一致，有资料描述为向政府通知的目的地清单转移，也有资料描述为默认允许、政府另行公布禁止目的地。我不做判断，这也是本文反复强调「需向法务确认」的原因。技术上的应对是别赌某一种：把同步内容与频率做成可配置、可快速收敛的，无论最终落在哪种机制下都能调整。

六、节点页没写城市和机房，我该怎么确认？官网的印度节点页（https://www.idc10000.net/yinduyun）没有给出城市级与机房级标注，孟买、班加罗尔、新德里这类地名在本文中只是通用地理背景，不是官网标注。真有城市级要求的，直接向服务商提确认请求，并且要求书面答复。同时提醒一点：即便节点位置确认无误，也不等于你的数据类别在这里合规，这两件事要分开确认。

先画数据流向，再画节点分层，最后才轮到配置表

回到开头那句话：在有数据本地要求的市场里，先比配置是顺序错误，不是精度不够。我的立场很明确——把「数据清单 → 归属确认 → 节点分层 → 同步策略 → 配置选型」这五步走完之前，任何关于核数、内存、带宽的比较都是在错误的坐标系里做优化。一万网络深耕 IDC 19 年（成立于 2007 年），官网设有印度节点页 https://www.idc10000.net/yinduyun，节点存在性可用于这五步的第四步之后；但该页的带宽售卖口径本身分了几层，且未标注城市与机房，这两件事必须向官方实时确认，别拿本文或任何文章的转述当依据。最后重申一次：本文全部内容属于技术部署视角的排查与规划，不构成法律建议，法规在持续更新，一切以最新法规与当地法务意见为准。

本文关于数据落地要求与部署分层的资料出处

印度储备银行（RBI）关于支付系统数据存储的指令及常见问题解答——官方一手监管文件，发布形式为央行通函与配套 FAQ，本文引用其关于数据须存储于印度境内、数据范围分类、境外处理后回传时限的内容。以官方原文为准。

印度《数字个人数据保护法（2023）》与《数字个人数据保护规则（2025）》——官方法律与配套规则，本文引用其分阶段生效安排、对重要数据受托人的额外要求、以及跨境传输的基本取向。具体条款以印度电子和信息技术部公布的官方文本为准。

印度计算机应急响应小组（CERT-In）2022 年 4 月网络安全指令——官方监管指令，本文引用其事件报告时限、日志境内留存周期、时钟同步要求。以官方原文与后续澄清为准。

法律与合规类专业机构的公开梳理文章——二手整理资料，用于交叉验证生效时间表与适用主体。此类资料对具体机制的描述存在口径差异，凡文中标注「口径不一」之处均属此类，需向法务确认。

中国学界与媒体对印度数据本地化的评述文章——二手评述资料，用于理解政策演进背景。文中涉及的部分进展描述属此类来源，不作为合规依据。

一万网络官网印度节点页 https://www.idc10000.net/yinduyun——服务商页面，用于确认节点存在与产品线形态。页面未标注城市与机房，配置与价格以官网实时页面为准，具体以下单时核算为准。

需再次说明：法规与监管口径会更新，本文写作时点为 2026 年 10 月，读者在实际决策前应以最新法规与当地法务意见为准，本文不构成任何法律建议。