移动代理还是住宅代理：反检测浏览器该选什么

移动代理（mobile proxies）和住宅代理（residential proxies）表面上解决的是类似的问题：两者都会用外部 IP 替换你的真实 IP。但对于反检测浏览器来说，这还不够。实际中，重要的是整套链路：IP 来自哪里、会话保持得是否稳定、GEO/时区/语言是否一致、是否存在 DNS 和 WebRTC 泄漏，以及浏览器配置文件本身看起来是否足够一致。代理会改变网络路由，但网站仍然能看到几十项浏览器和系统参数。

如果你想先快速回顾一下基础知识，先看看什么是代理服务以及什么是浏览器数字指纹。反欺诈标记最常出现在网络、cookies、配置文件设置和 fingerprint 参数的交界处。

• 选择移动代理，如果你处理的是敏感的 consumer 场景，需要尽可能“普通”的移动 IP，并且愿意接受较低的可预测速度和会话稳定性。
• 选择住宅代理，如果你更看重长时间会话、养号、市场平台、e-commerce、账号管理，以及清晰的“一个配置文件 — 一个 IP”逻辑。
• 选择服务器 / 数据中心代理，如果你的核心要求是速度、规模和成本，而目标平台对 datacenter ASN 不算太敏感。
• 对于登录和长操作来说，起决定作用的不只是 IP 类型，还有粘性会话（sticky session）。而对于大规模数据采集，更重要的是IP 轮换（rotating IP）。
• 好的代理不能替代反检测浏览器：没有一致配置文件的 IP 仍然会留下痕迹。

这张表的逻辑建立在移动、residential 和 datacenter 网络之间的差异之上，同时基于这样一个事实：sticky session 更适合登录和多步骤场景，而 rotating mode 更适合 bulk collection。

简短回答：用两句话说该怎么选

什么时候选择移动代理

移动代理（mobile proxies）是来自 4G/5G 网络的 IP。通常在平台对“不像普通用户的流量”特别敏感，并且移动网络类型本身就显得自然时，人们会选择它们。实际中，这最常见于社交平台、部分 consumer 服务、一些注册、找回访问权限以及面对非常“紧张”的反欺诈系统的场景。在代理网络的官方文档中，mobile pool 通常被描述为更“trust-heavy”，但与 broadband residential 相比，它们也更慢、更不稳定。

关键点在于：移动代理有用，不是因为它们“神奇地不会被封”，而是因为它们有时更符合预期的网络上下文。如果你的场景是长工作会话、账号养号和可重复的操作路径，那么没有良好会话控制的移动 IP，可能反而比稳定的 residential/ISP 方案更难用。

什么时候选择住宅代理

住宅代理（residential proxies）使用真实的 consumer 连接。对于反检测来说，它们常常是“网络自然度 / 可控性 / 失误成本”这三者之间最理性的选择。尤其是当 речь 不是指一般意义上的 rotating pool，而是稳定的 residential IP，或者 static residential / ISP 这种格式时——在这种情况下，配置文件需要在同一个地址上持续运行数周。

如果任务是养号、登录、市场平台、e-commerce、长会话、手动管理后台、团队之间传递配置文件，或者精细化的 multi-accounting，那么 residential 通常比 mobile 更实用。这里通常更重要的不是“不惜一切代价追求最有信任感的 IP”，而是可预测的网络：同一个 IP、同样的 GEO 历史、同样的 cookies、同样的行为逻辑。

什么时候服务器代理就够用了

服务器 / 数据中心代理（datacenter proxies）是来自商业数据中心的 IP。它们通常速度最快、计费模式最清晰，也最方便扩展规模。如果平台对 ASN 不太苛刻，而你更在意吞吐量、响应速度和大规模能力，那么 datacenter 代理往往能更便宜、更好地完成任务。代理提供商的官方 docs 也明确把它们归类为 high-speed data collection 以及其他更看重 pure performance 而非 IP 最大“人类感”的场景。

说得简单一点：不要只是因为 mobile 听起来“更强”就去买它。如果你在做 QA、监控、部分 scraping 任务、测试落地页、收集公开数据，或者服务于那些不算太严格的网站，服务器代理可能是更合理的选择。

什么是移动代理、住宅代理和服务器代理

移动代理：它们是如何工作的

移动代理，是通过移动运营商的 IP 地址转发流量的代理，也就是通过 cellular 网络，而不是普通家庭 broadband。这也正是为什么它们在网站看来，通常更像普通手机或移动调制解调器的流量，而不是数据中心地址。同时，移动网络在延迟和稳定性上通常不如固定 broadband 连接那样可预测。

在反检测语境中，这意味着一件很简单的事：如果平台“喜欢” consumer/mobile traffic，mobile 就很好；但如果你需要的是同一个长时间会话的完美稳定性，它们未必是最好的选择。

住宅代理：它们是如何工作的

住宅代理，是来自 consumer 网络的 IP，通常是家庭 Wi-Fi 或 broadband。在 practical anti-detect work 中，把它们分为两种模式会更有帮助：rotating residential pool 和 static residential / ISP。前者提供 IP 多样性，适合分散请求。后者更接近“一个配置文件 — 一个地址”的模型，更适合 long-session 任务。供应商文档通常会将 residential 描述为 real consumer connections，而将 static residential / ISP 描述为来源于 consumer/ISP、但更稳定的固定方案。

简而言之：residential 不是单一产品，而是一整类解决方案。也正是在这里最容易选错：人们拿 mobile 去和“泛泛意义上的 residential”比较，但实际上，他们真正需要的，要么是用于扩展的 rotating residential，要么是一个能让账号长期稳定运行的 static residential/ISP。

服务器 / 数据中心代理：基本参考点

服务器 / 数据中心代理，是来自商业数据中心的 IP。它们最大的优势是速度、连接稳定性，以及在大规模使用时更友好的成本。缺点则是，这类网络不像普通用户那样自然。因此，datacenter 不应该被自动排除：对于 scraping、QA、监控、测试、内部工具，以及许多并不太敏感的任务，它们仍然是完全可行的选择。

为什么代理 ≠ 完整的反检测

代理服务器是客户端与网站之间的中介，它改变的是请求的网络层。但 BrowserLeaks、Whoer 和 Pixelscan 检查的不只是 IP。它们还会显示本地时间、语言、屏幕分辨率、User-Agent、WebRTC、DNS、字体、硬件参数以及其他组成 fingerprint 的信号。Pixelscan 还特别提醒：即使会话之间只是 IP、timezone 或环境发生了细微变化，也可能产生 inconsistent results，并触发 CAPTCHA 或封禁。

**重要：**代理本身并不能解决 fingerprint 问题。

如果 IP 看起来“干净”，但配置文件同时暴露出不匹配的语言、错误的时区、泄漏 WebRTC，或者在活跃会话中途发生变化，那么你得到的不是保护，而是给反欺诈系统呈现出一幅相互矛盾的画面。这也正是为什么反检测浏览器和代理不是可互相替代的工具，而是一套方案中的两个部分。

按 7 个关键标准进行比较

表中的 “trust” 不是网站的正式指标，而是对这种网络类型在实际中有多像普通用户的经验判断。比较基础包括：IP 来源类型、session behavior、speed/stability，以及官方 docs 中对 residential/static/datacenter 方案的典型模型描述。

平台对它们的信任程度

如果非常粗略地说，对于敏感 consumer 平台，梯度通常是：mobile → residential → datacenter。但这只能作为经验法则。没有哪一种 IP 类型会自动“获胜”。同一个 mobile IP 可能会被不合逻辑的 fingerprint 搞砸，而 residential 也可能因为活跃登录过程中更换 IP 而被毁掉。

因此，正确的问题不是“哪一种永远更有信任度”，而是“哪一种网络类型更符合这个配置文件和这个场景”。

会话稳定性与“粘性”IP

对于多步骤操作，逻辑很简单：登录、养号、购物车、checkout、填写表单、反复检查邮箱以及手动管理账号，通常都更适合在**粘性会话（sticky session）**下进行。官方关于 rotating/sticky modes 的 docs 也明确将 sticky 用于 account management、form filling 和 checkout flows。同时，sticky 并不意味着 permanent：如果底层 peer 离线了，IP 仍然可能自动切换。

也正因为如此，对于工作账号来说，通常更重要的不是“超高频轮换”，而是可预测性：一个配置文件、一个 session ID、一个活跃会话中的一个 IP。

速度与吞吐能力

如果你需要的是纯粹的性能，第一名几乎总是 datacenter。Residential 通常更慢，而 mobile 对延迟和网络波动则更为敏感。这并不意味着 mobile “不好”——只是它们的任务不同。购买它们不是为了 throughput，而是为了网络上下文。

地理位置、ASN、GEO 精度

对于反检测来说，仅仅匹配国家还不够。更重要的是，整段历史看起来都要合理：IP、本地时间、语言、ASN 和 fingerprint 不能向网站讲述不同的故事。Whoer 会专门检查系统时间是否与 IP 定位一致，BrowserLeaks 会显示 local time 和系统语言，而 Pixelscan 会把 timezone 和 language 纳入 fingerprint 分析。

由此得出一个实践规则：不要只按国家标识来选代理。要看配置文件的环境，是否与你的这个 IP 向网站“承诺”的内容一致。

价格与计费模式

只按着陆页上的数字比较代理，是个错误。重要的是，你到底买的是什么：固定 IP、带宽池、rotating gateway、sticky session、端口、设备，还是独立的 change-IP 机制。在 proxy types 的文档中通常可以看到，datacenter 和 static residential/ISP 更常以 per-proxy 模式出售，而 rotating residential 则通常按带宽计费。

在实践中，这意味着一件事：购买之前，先决定你需要的是给配置文件用的一个长期地址，还是一个用于轮换的大池子。然后再去比较价格。

轮换：什么时候有用，什么时候有害

IP 轮换在需要高体量的场景中很有用：scraping、crawling、bulk data collection。Sticky session 则在需要连续性的场景中更有用：授权、单个账号内的操作、多步骤流程。这完全符合 rotating vs sticky modes 的文档说明。

最常见的错误，就是“以防万一”按定时器开启轮换，然后再疑惑为什么活跃会话开始显得可疑。如果配置文件已经登录并保持连续活动，那么在流程中途更换 IP，通常是有害的。

扩展到数十 / 数百个配置文件

配置文件越多，混乱越不被原谅。规模一上来，“只是买个代理”就不够了。你需要清晰的命名规则、IP 与配置文件的绑定、快速的状态检查，以及方便的大批量导入。在 Undetectable 中，为此有 Proxy Manager：它支持添加单个代理、导入/导出、状态检查，以及类型、host、port、用户名/密码和 change IP 链接字段。

简而言之：在 5 个配置文件以内，也许还能靠手工管理。再往上，代理类型的选择就已经和 workflow 分不开了。

如何针对具体任务选择代理类型

在选择之前，先过一遍这个 mini decision-tree 会很方便：

1. 涉及登录、cookies、养号和长会话吗？ 重点考虑 sticky residential 或 static residential/ISP。
2. 在敏感平台上需要尽可能 consumer-looking 的 IP 吗？ 考虑 mobile。
3. 需要数千次请求，并且速度比网络的“人类感”更重要吗？ 从 datacenter 开始。
4. 平台很严格，但请求量也很大吗？ 使用 rotating residential。
5. 你在处理账号吗？ 优先考虑的不是轮换，而是配置文件和会话的稳定性。

选择矩阵基于 bulk collection 和 multi-step workflows 之间的差异：rotating mode 适合大体量，sticky/static 则适合连续性和账号管理。

SMM 和社交平台运营

对于社交平台来说，最常赢的不是最贵的代理，而是最一致的代理。如果你在做社交平台多账号管理，关键在于不要让配置文件彼此交叉、不要在不合适的时候切换 IP，并且为每个账号维持一个合乎逻辑的网络上下文。Undetectable 关于 SMM 的文档本身也直接强调：反检测并不能替代 GEO、IP 和 provider 的有效性——这些需要优质代理来保证。

实践规则是：如果这是手动账号操作和养号，从 sticky residential/static residential 开始。如果平台对网络类型特别挑剔，再在有限的配置文件池上测试 mobile。

E-commerce、市场平台、支付场景

对于 e-commerce 和 checkout 场景来说，最有价值的是连续性。网站期望看到的是：同一个用户，带着相同的 cookies、同样的设备和同样的 IP，继续完成操作，而不是在购物车中途“瞬移”到另一个地址。Sticky sessions 在官方文档中被明确推荐用于 account management 和 checkout bots；与此同时，Pixelscan 也提醒，会话之间的 IP 和环境变化会带来 inconsistent fingerprint signals。

因此，在这里，通常是稳定的 residential/ISP IP 更容易胜出，而不是 rotating pool。

Web scraping、监控、QA

对于 scraping，你并不需要自动去买 mobile。如果任务是大规模抓取公开页面，通常更合理的起点是 datacenter 或 rotating residential。Datacenter 提供速度和价格优势，rotating residential 在分散负载时则能提供更柔和的 consumer footprint。官方 proxy docs 也直接区分了这些场景：datacenter 用于 high-speed collection，rotating mode 用于 bulk data collection。

只有当网站本身，或者访问逻辑本身，强烈依赖 mobile-like network behavior 时，mobile 才真正有意义。

流量套利与自动化

在 arbitrage 中，很少存在一种代理类型能“包打天下”。对于多账号和流量套利，更有效的方法通常是按阶段拆解任务：某些环节需要为账号提供稳定 IP，某些环节则需要用于采集、检查器或辅助操作的 rotating pool。Undetectable 关于 traffic-use-case 的文档，同样也是围绕独立配置文件、cookies 和 IP 变更作为一个独立层来构建逻辑，而不是把它当成唯一工具。

也正因为如此，在自动化中，正确的思路不该是“哪种代理最好”，而是“哪种代理 + 配置文件 + workflow 的组合，最适合这个具体阶段”。

账号养号和长时间会话

养号喜欢稳定。配置文件历史中的跳变越少越好。对于长期会话来说，通常 static residential/ISP 或 long sticky residential sessions 更合适。只有当平台本身，或场景本身，确实会从 mobile network context 中受益时，mobile 才是必要的。

如何将代理与反检测浏览器中的配置文件绑定

Undetectable 中的浏览器配置文件，是一个独立实体，拥有自己的设置、扩展、cookies、代理和配置。根据该服务的 docs，正是这些设置的独特性，才让网站把每个配置文件视为一个独立用户。这意味着，代理也必须不是“按整体任务”去选，而是按具体配置文件的生命周期来选。

“1 个配置文件 = 1 个 IP”规则

这不是自然规律，而是最佳实践规则。一个工作中的配置文件，至少在活跃会话期间，应该拥有自己稳定的 IP。Undetectable 明确基于一种模型：每个配置文件都在参数组合上独一无二，包括 IP、cookies 和历史记录；而 proxy docs 中关于 sticky sessions 的描述，也专门提到了防止不同会话之间 IP 交叉。

如果你让很多配置文件共用同一个地址，那你就是在本该由反检测切断关联的地方，亲手制造关联。

什么时候不能在活跃会话中更换 IP

如果配置文件已经登录、持有 cookies，并且正在执行连续操作，那么通常不能在这个会话中途更换 IP。Pixelscan 直接指出，会话之间 IP、timezone、resolution 或 extensions 的微小变化，都可能导致 inconsistent fingerprints 和类似 CAPTCHA 或 bans 的 red flags。

一个简单规则：登录、养号、checkout、手动操作 —— 都用同一个 IP；轮换 —— 放在登录前、流程结束后，或用于单独的 bulk 任务。

为什么必须协调 GEO、timezone、language 和 WebRTC

反欺诈系统看到的并不只是 IP 所在国家。BrowserLeaks 会显示 system language 和 local time，Whoer 会注意系统时间是否与 IP 定位匹配，Pixelscan 则会把 timezone、language、headers、fonts 和 hardware 都纳入 fingerprint 分析。另外，Undetectable 的 docs 还建议选择与设备匹配的操作系统配置，并使用默认的指纹设置；在配置文件的 default settings 中，还会单独设置 OS、browser、screen、proxy 和 languages。

否则就会出现经典的反检测错误：IP 说“柏林”，配置文件说“莫斯科”，语言是 “pt-BR”，而 local time 和 WebRTC 又在讲第三个故事。

该选 HTTPS 还是 SOCKS5

在浏览器层面，这两种方式都可用，但逻辑不同。MDN 将 http 描述为 HTTP proxy，或者在 HTTPS 情况下通过 SSL CONNECT；而另一份关于 HTTP tunneling 的指南则解释说，CONNECT 方法会打开一条通向目标资源的双向隧道。根据 RFC 1928，SOCKS5 是一种独立的协议，客户端会先协商认证方法，然后发送 relay request；在浏览器 APIs 的 MDN 文档中，SOCKS 还与 proxyDNS 选项相关，也就是 DNS 请求究竟在哪里解析的问题。

从实践上说，这意味着：

• HTTPS CONNECT —— 适合普通浏览器流量，兼容性好，工作模式标准。
• SOCKS5 —— 在你需要更灵活的传输层，并且会单独控制 DNS 行为时，往往更方便。
• 在有争议的情况下，不要猜：配置好之后，用测试来检查泄漏。

认证方式：登录名/密码 vs whitelist

从实践角度看，选择很简单。如果你需要从不同机器、不同网络，或者动态出口 IP 下工作，那么用户名/密码会更方便。如果你的工作 IP 稳定，并且不想在每个客户端里存储凭据，那么 IP whitelist 会更方便。代理服务的官方 docs 也几乎是这样表述的：user/pass 适合来自不同位置或 dynamic IP 的访问，而 IP whitelisting 适合你总是从一个已知地址工作。

在 Undetectable 本身，这一点也体现在界面中：Proxy Manager 提供了类型、host、port、登录名和密码字段，以及可选的 IP 更换链接；同时支持批量导入和状态检查。如果你需要的是面向普通浏览器的基础系统方案，还可以参考单独的文章：如何在 Chrome 中配置代理。

如何检查这套配置是否正确

在把代理绑定到配置文件之后，不要立刻进入工作账号。先检查 IP、DNS 和 WebRTC，然后通过 Whoer 检查匿名性，最后再通过 Pixelscan 检查 fingerprint。这比事后从 re-verification 或封禁中把配置文件救回来要快得多。

检查 IP、DNS 和 WebRTC

BrowserLeaks DNS Leak Test 会显示，浏览器在解析域名时实际上使用了哪些 DNS 服务器。BrowserLeaks WebRTC Leak Test 则会专门检查 WebRTC 是否通过 STUN 暴露了本地 IP 或公共 IP。这两项都非常关键，因为即使外部 IP 很“干净”，如果 DNS 还在走你真实 provider，或者 WebRTC 暴露了本地网络，那么一切都白费。

在 BrowserLeaks / Whoer / Pixelscan 中要看什么

在 BrowserLeaks 中，查看 IP、DNS、WebRTC，以及像 local time、system language 等 JavaScript 参数和其他 fingerprint signals。在 Whoer 中，看 IP、WebRTC/DNS leaks、privacy score，尤其要看系统时间是否与 IP 定位冲突。在 Pixelscan 中，则看 location、date & time、screen、fonts、User-Agent、language、hardware、headers，以及配置文件在不同会话之间的一致性。

如果这几个服务中的任何一个显示出矛盾，那么问题就应该在登录之前修复，而不是之后。

配置文件启动前检查清单

该 checklist 基于 BrowserLeaks、Whoer 和 Pixelscan 实际能看到的检查项：IP、DNS、WebRTC、local time、language、headers、hardware 和 fingerprint consistency。

这些测试不仅要在第一次启动时做，也应该在创建新配置文件、更换代理和更新浏览器之后重复进行。Undetectable 本身也会在自己的 checker 页面中建议，把新配置文件和配置变更的检查，当作 quality-control 步骤，而不是一次性的形式流程。

常见错误

免费代理

免费代理几乎从来不值得省下来的那点钱带来的麻烦。即使在 Undetectable 最基础的 proxy-explainer 中，也明确提到这类资源通常负载很重，而且没人能保证其技术状态和稳定性。对于工作账号来说，这意味着更多噪音、意外掉线，以及不可预测的 IP 声誉。

多个配置文件共用一个 IP

如果你有多个配置文件，而它们都通过同一个 IP 对外显示，那么你就是在主动制造关联。Undetectable 把配置文件设计为彼此独立的实体，各自拥有自己的 cookies、proxy 和配置；而 sticky-session docs 也专门提供了避免不同会话 IP 冲突的模式。因此，反过来的做法——让多个独立配置文件共享同一个 IP——几乎总是个坏主意。

在错误的时机进行轮换

轮换适合 bulk，不适合活跃的已登录会话。如果你在配置文件已经与平台交互时更换 IP，你就破坏了 continuity。而 Pixelscan 也明确警告，IP 和环境的变化可能会导致 inconsistent fingerprint 和 red flags。

语言 / 时区 / GEO 不匹配

这是最容易被低估的错误之一。很多人只看 IP 国家，却忘了 BrowserLeaks 能看到 local time 和 language，Whoer 会比较 system time 和 IP location，而 Pixelscan 会把 timezone 和 language 纳入整体 fingerprint 画像。

错误选择协议

问题不在于 SOCKS5 “总是更好”，或者 HTTPS “总是更差”。问题在于，人们机械地选择协议，却不去考虑兼容性、认证和 DNS-behavior。MDN 专门描述了 HTTP/CONNECT 和 SOCKS 之间的区别，也说明了在 proxying 场景中，DNS 问题不能被视为自动解决。

在 static residential 已经足够的地方购买 mobile

Mobile 并不是通用升级版。如果你的任务是长时间工作会话、平稳养号、稳定账号，以及尽可能减少意外网络波动，那么 static residential/ISP 通常更理性。只有当平台确实需要这种网络上下文时，mobile 才有意义，而不是因为它听起来“最有信任感”。

FAQ

1. 移动代理和住宅代理有什么区别？

移动代理通过 4G/5G 的 cellular 网络转发流量，而住宅代理通过 consumer broadband/Wi-Fi。实践中，mobile 更常在敏感 consumer 场景中占优，而 residential 则在稳定性和长会话便利性方面更强。

2. 对于反检测浏览器，mobile、residential 还是 datacenter 更好？

不存在一种“永远最好”的方案。对于社交平台和部分敏感 consumer 任务，人们通常会测试 mobile 或 sticky residential；对于 long-session 和 marketplace 场景，则使用 static residential/ISP；而对于速度和规模，datacenter 更合适。

3. 什么时候需要静态 IP，什么时候需要轮换？

静态或 sticky IP 适合登录、养号、checkout，以及单个会话中的任何连续操作。轮换则适合 scraping、crawling 和 bulk collection，在这些场景里，更重要的是体量和 IP 多样性。

4. 为什么不能在多个配置文件上使用同一个 IP？

因为你会主动在本该彼此独立的配置文件之间制造网络关联。Undetectable 将配置文件设计为独立实体，而 sticky-session workflows 也会专门支持不同会话之间 IP 的唯一性。

5. SOCKS5 和 HTTPS 该选哪个？

两者都可以。HTTPS CONNECT 很适合普通浏览器流量和标准兼容性；SOCKS5 是一种独立的代理协议，拥有自己的认证方式以及 DNS/resolution 方面的细节，这些都需要在配置完成后通过测试来验证。

6. 为什么好的代理仍然不能替代反检测浏览器？

因为网站看到的不只是 IP，还有 fingerprint：local time、language、headers、fonts、hardware、WebRTC 和其他信号。代理负责网络层，反检测负责浏览器层。两者都需要。

7. 配置好之后，如何检查 DNS 和 WebRTC 泄漏？

先让配置文件通过 BrowserLeaks：分别跑 DNS Leak Test 和 WebRTC Leak Test。然后在 Whoer 中检查整套组合，最后用 Pixelscan 完成对整体一致性的检查。

8. 工作账号值得使用免费代理吗？

不值得，尤其当你在乎工作账号和失误成本时。即便是 Undetectable 的基础 explainer 也指出，免费代理通常负载过重，而且其稳定性无人保证。

结论

如果你需要一个尽可能简短的结论，那就是：

• mobile —— 当平台对网络类型特别敏感，并且你需要 mobile-looking traffic 时；
• residential / static residential / ISP —— 当你更看重长期稳定会话、养号、市场平台、社交平台，以及精细的配置文件管理时；
• datacenter —— 当速度、规模和经济性排在第一位，而不是网络最大的“人类感”时。

但在反检测领域，代理类型只是解决方案的一半。另一半是配置文件：它的 fingerprint、cookies、语言、timezone、轮换逻辑，以及是否存在泄漏。因此，真正该选择的不是“最有信任感的 IP”，而是最符合任务逻辑的整套组合。

如果你想直接进入实践，可以打开代理服务商目录，了解反检测浏览器的功能并下载 Undetectable。在产品中起步，只需要创建一个配置文件、绑定代理，然后在正式登录工作账号之前跑一次基础检查。

注释与编辑说明

• 文中有意不列出服务商价格：计费模式和 availability 变化太快，并且取决于国家、IP 类型、sticky/rotating 模式和具体提供商。
• static residential、ISP proxy 以及相近名称，在不同提供商那里可能标识的是略有差异的产品；本文强调的是实践任务——你究竟需要的是给单个配置文件用的稳定 IP，还是一个 rotating pool。
• Sticky session 不等于 permanent IP：在 peer/mobile 网络中，如果底层设备离线，或者会话过期，地址仍然可能变化。
• 没有任何一种代理类型，也没有任何一个反检测浏览器，能提供“零封禁概率”：IP、fingerprint consistency、cookies、账号历史和行为信号依然会发挥作用。
• 任何新配置文件，在更换代理、更新浏览器或修改 fingerprint 设置之后，都值得重新检查。

Undetectable Team 反侦测专家