德国代理：网络、城市与地区核查

出发点

把国家识别、网络身份和地区页面行为分开，构建一次有用的德国代理试用。ipvolt 仍在开发中；德国库存和运营商可用性尚未确认。

确定你的德国测试必须证明什么

德国代理应当让你的请求获得一个满足德国位置需求的出口地址。这可能意味着被你的应用识别为德国、一个特定的城市结果，或者一条经由特定网络、有据可查的连接。在把国家选择器当成完整规范之前，先决定其中哪一项对你重要。

考虑三种不同的任务：检查自家店铺的德国版本、复现一位 O2 移动用户报告的问题，以及验证柏林的门店定位器。第一项需要受控的地区设置；第二项需要相关的网络证据；第三项需要一个明确定义的位置输入。一次成功的页面加载无法同时解决这三项。

写下页面或端点、它所做的判定、它使用的输入，以及什么样的证据算作通过。如果仅凭国家识别就能满足你的需求，就把城市和运营商设为可选。如果指定网络是必需的，那么即使页面看起来正确，一个无法解释的网络标签仍然是未解决的需求。

使用最新的德国网络版图

联邦网络局（Bundesnetzagentur）的移动用户统计表把 Telekom、Vodafone、Telefónica 和 1&1 Mobilfunk 列为网络运营商。它还把较早的 D1 和 D2 名称对应到 Telekom 和 Vodafone，并把 O2 与 Telefónica Germany 关联起来。这些名称有助于解读供应商的描述；监管机构的表格并不标识可用的代理出口。

把零售品牌、移动网络运营商和观察到的 IP 网络组织放在不同的字段里。零售商可能使用另一家公司的基础设施，而一个熟悉的电信集团可能提供多种接入类型。针对实际样本索要当前的对应关系，而不是照搬旧文章里的比较表。

• Telekom 或 D1：索要代理供应商实际支持的确切选项，以及该选项如何针对观察到的地址进行验证。
• Vodafone 或 D2：除名称之外还要记录接入技术；仅凭品牌匹配无法确定移动接入。
• O2 或 Telefónica：把 O2 当作品牌背景，然后弄清所提供出口背后的接入产品和网络证据。
• 1&1：把它当作第四家移动网络运营商来评估，并考虑其全国漫游安排；不要简单地把它描述为 O2 的转售商。

理解 1&1 漫游可能改变什么

在 2025 年 11 月 11 日的公告中，1&1 宣布已完成将客户迁移到自有网络。其当前的网络查询 FAQ 称，在 1&1 自有网络不可用的地方，客户使用全国漫游合作伙伴 Vodafone 的天线。在阅读关于 1&1 服务的旧描述时，这一组合很重要。

客户关系、承载连接的无线网络，以及通告其互联网地址的网络，回答的是不同的问题。漫游描述并不是一条「每个 1&1 样本都必须显示 Vodafone ASN」的规则。1&1 标签也无法确定某个具体请求由哪套无线基础设施处理。询问供应商的运营商选择器实际控制的是哪一层。

如果你需要复现无线网络问题，就索要关于接入连接和漫游状态的证据。如果你需要复现基于互联网地址网络分类的行为，则保留该地址和分类器的结果。当这一区分无法确定时，把试用描述为对所提供选项的一次抽样，而不是对某个特定天线网络的已验证测试。

区分移动、固定和家庭接入

德国家庭互联网的品牌命名说明了产品名称为何需要解读。Telefónica 描述的 O2 家庭接入通过基础设施合作伙伴以光纤、有线电视网络和 DSL 提供，同时还有通过 4G 或 5G 交付的 O2 Homespot 产品。因此，在家中使用的连接不一定是固定线路连接。

对于固定住宅试用，询问样本使用的是 DSL、有线电视网络还是光纤，以及供应商如何确定其来源。对于移动试用，询问移动接入如何有据可查。一个注册在电信组织名下的德国地址提供了有用的背景，但它本身无法提供这些答案。

避免在比较进行到一半时更换类别。如果一个候选提供固定宽带，另一个提供移动接入，先记录这一差异，再比较应用结果。如果你的任务两者都接受，就明确说出来。还要询问参与的连接是如何获得此用途授权的；一个网络公开存在，并不能证明代理供应商有权提供它。

把柏林和法兰克福当作独立的需求

把德国、请求的城市和位置来源放在不同的列里。法兰克福的结果不会仅仅因为两者都是德国城市就满足柏林专属的需求。反过来，如果评估明确只要求国家识别，城市不匹配也不必判为失败。在看到结果之前先明确规则。

MaxMind 说明，IP 地理定位的准确度随网络类型、地址族等因素而变化，不同数据库之间的结果也可能不同。其数据无法定位到具体的住户或街道地址。把城市标签当作需要对照你应用的位置来源进行评估的估计值，而不是用户或设备物理位置的证明。

移动覆盖图回答的是另一个问题。联邦网络局表示，其地图根据运营商提供的信息预测室外接收情况；建筑物、地形、设备和网络负载都会影响实际接收。柏林周围的一片彩色区域不能证明代理供应商有柏林出口，也不能证明某个地址会被归类到柏林。

对于门店定位器测试，如果应用支持，就使用一个显式的测试位置，并单独测试其基于 IP 的默认值。记录每个结果是由哪个输入产生的。这样可以防止把手动选择的柏林地址误当成网络出口被识别为柏林的证据。

捕获目标站点看到的地址

先按照相关的 curl 配置指南确认网关连接。然后使用一个获批的诊断目标，它会报告自己观察到的源地址。查询网关主机或你工作站的地址测试的是路径的另一部分。如果你运营的目标站点位于 CDN 之后，使用其受信任的连接元数据，而不是任意由客户端提供的转发请求头。

对每个观察到的出口，记录时间戳和地址族。RIPEstat 的 Network Info 端点使用 RIPE RIS 数据提供所属前缀和通告 ASN（一个或多个）。把查询结果和时间作为路由证据保留，然后就与供应商网络描述之间的任何不匹配索要解释。

RIPE 的数据库文档警告，country 属性无法可靠地把地址映射到国家。因此，一个 DE 注册字段不足以证明你的测试所要求的位置。把注册、路由和地理定位结果分开保存，未知的接入细节保持未解决，而不是从组织名称推断。

控制德语和地区设置

德语页面不能证明出口在德国。W3C 说明，Accept-Language 表达的是语言偏好，不应单独用来判定用户的区域设置。说德语的人可能在别处，身在德国的访客也可能偏好另一种语言。你的测试应当保留这一区分。

以一次假设的德国店铺检查为例，记录语言偏好、所选市场、货币、账户状态、Cookie 和浏览器时区。一个示例配置可能使用 de-DE、EUR 和 Europe/Berlin。这些是你选定的应用输入，不是代理必然会改变的值，也不是请求来自德国的证据。

基线使用一个全新的测试配置文件。保持出口选择固定，每次只改变一个地区输入，并从你自己的应用规范中保存预期行为。一个被记住的市场 Cookie 可能解释一个原本看起来像位置失败的结果。当页面使用配送地址和浏览器位置权限时，把它们当作额外的输入。

构建一个小型验收矩阵

下面的用例构成一个示例性的评估矩阵。它们是建议的流程，不是 ipvolt 执行过的测量，也不是任何供应商支持这些选项的承诺。只选择与你的工作负载相关的用例，并在申请试用之前写好验收条件。

• 国家用例：请求德国并保持浏览器配置文件固定。当约定的位置来源把观察到的出口识别为德国，且应用中依赖国家的行为符合其规范时，判为通过。如果城市不在范围内，就把它记录为参考信息。
• 城市用例：只有在供应商文档说明支持城市选择时才请求柏林。只有当约定的来源满足你的柏林标准时，位置检查才判为通过。返回德国但缺少所需城市的结果，在本用例中记录为未解决。
• 网络用例：请求你需要的具体接入类型和网络。保留观察到的前缀、ASN 以及供应商对其选项的说明，相关时包括漫游。国家匹配但移动接入没有文档依据，不能完成本用例。
• 区域设置用例：保持同一个有据可查的出口选项不变，比较全新配置文件与你受控的德国地区配置文件。把页面行为与你的规范对照；不要把正确的货币或翻译提升为位置证明。

扩大试用之前先解决失败

对每个选定的用例，先用相同的会话设置连续发送 2 个诊断请求，然后做 1 次获批的应用检查。设定请求截止时间，基线阶段禁用自动重试，并在请求之间停顿。这个小的起始序列能暴露配置差异；它无法估计地址池规模、正常运行时间或长期成功率。

把失败的尝试与成功的尝试保留在同一张工作表里。超时意味着位置未知。德国结果正确但 ASN 无法解释，意味着网络需求仍未关闭。出口正确但语言出乎意料，需要调查地区状态。当相同设置在不同客户端之间表现不同时，参考相关的环境变量和超时指南。

在进行更大规模的评估之前，询问国家、城市或网络选项不可用时会怎样、是否可能回退，以及在文档规定的粘性会话期间哪些内容会保持。如果连续性很重要，按你的工作流所需的间隔安排一次单独的后续检查。保留请求的选项、时间、观察到的结果和支持团队解释的脱敏证据。

ipvolt 尚未获得供应协议，德国库存或运营商可用性也未得到确认。加入候补名单只是登记意向；它不预留德国地址、城市、运营商或交付日期。用本指南定义未来的服务在你依赖它之前必须证明什么。

上线前

• 分别定义国家、城市、网络和应用行为的验收条件。
• 把零售品牌、漫游无线网络和互联网路由证据区分开。
• 确认实际的接入技术，尤其是家庭互联网产品。
• 记录目标站点观察到的地址，以及带日期的位置和 ASN 查询结果。
• 独立控制德语、货币、账户状态和时区。
• 保留未解决的结果，并在扩大规模之前确认回退和会话行为。