如果你原来使用 922 S5，迁移时最重要的不是重新学习一套代理协议，而是把原来的“本地客户端、端口转发、IP 提取、会话保持和浏览器配置”分别对应到新的代理接入方式。
922 S5 用户常见的疑问包括：原来的 127.0.0.1 本地端口怎么办、账密和白名单应该怎么选、指纹浏览器还能不能继续使用、原来长期保持的 IP 应该如何替代。本文按“旧功能 → 新配置 → 验收方式”整理迁移步骤，重点解决这些实际问题。
快速对应：
- 原来连接本地端口 → 改为当前代理产品提供的远程 Host / Port。
- 原来由 922 客户端处理认证 → 改为账密认证或来源 IP 白名单。
- 原来在客户端里选择地区和节点 → 改为后台筛选或账号参数。
- 原来需要一段时间保持同一出口 → 使用当前产品支持的粘性会话或长效方案。
- 原来通过
127.0.0.1接入 Python / Node.js → 代码迁移单独按远程代理配置处理。
一、922 S5 迁移到 IPWeb，原来的功能怎么对应？
922 S5 与 IPWeb 的界面和接入方式并不是一一对应的。迁移时不要只找“同名按钮”，应先确认旧功能背后的真实需求，再选择新的实现方式。
| 922 S5 原使用方式 | 真实需求 | 迁移后的处理方式 | 怎么验收 |
|---|---|---|---|
| 本地端口转发 | 让程序或浏览器通过代理出网 | 使用当前产品提供的远程 Host、Port 和认证信息 | 检查实际出口 IP 是否已经变化 |
| 客户端选择国家 / 地区节点 | 控制出口地区 | 通过后台筛选、账号参数或对应产品的地区设置完成 | 核对最终出口的国家、州或城市 |
| 短期保持同一个 IP | 一个任务周期内保持出口稳定 | 使用当前产品支持的粘性会话或长效方案 | 连续请求观察出口是否按预期保持 |
| 长期固定一个 IP | 长期使用固定公网出口 | 根据业务需要选择静态住宅等固定出口产品 | 多次重连后核对出口是否仍为同一地址 |
| 指纹浏览器批量环境 | 给不同浏览器环境配置不同代理 | 使用指纹浏览器的自定义代理、智能粘贴或批量导入功能 | 逐个环境检查代理连通性和出口地区 |
程序连接 127.0.0.1 |
让 Python / Node.js 通过代理请求 | 改为远程代理端点，并重新配置认证、环境变量和 Session | 用最小请求确认程序实际经过新代理 |
计费方式也不建议直接按“922 按条、IPWeb 按流量”简单对应。IPWeb 不同产品可能采用不同计费方式，迁移前应先确认自己使用的是动态住宅、静态住宅还是其他产品，再按当前价格页和后台规则判断。
二、922 本地客户端和远程代理有什么区别？
922 S5 用户最明显的变化，是程序或浏览器不再依赖本机客户端导出的代理端口。旧链路通常可以理解为：
应用 / 浏览器 → 127.0.0.1:本地端口 → 922 客户端 → 代理网络 → 目标网站迁移到远程代理后，常见链路变成：
应用 / 浏览器 → 远程代理 Host:Port → 出口节点 → 目标网站因此真正发生变化的主要有三项：第一，不再把 127.0.0.1 当作代理服务器；第二，认证从本地客户端内部处理，变成由程序、浏览器或来源 IP 完成；第三，地区选择、IP 切换和会话保持要按照新产品的规则重新设置。
这不代表远程代理天然“更高级”或一定更稳定。迁移是否顺利，仍取决于代理端点、网络质量、认证配置和业务程序本身。这里重点解决的是连接方式变化，而不是给两种架构做绝对优劣判断。
三、迁移后该选 IP 白名单还是账密认证？
迁移时不要把“API 提取”和“账密认证”简单理解成两种完全不同的代理。更实用的判断方式，是看实际运行环境是否有稳定的公网来源地址，以及你使用的客户端支持哪种认证方式。
| 场景 | 更适合的方式 | 需要注意 |
|---|---|---|
| 固定云服务器或固定办公公网 IP | 可考虑来源 IP 白名单 | 应添加实际连接代理网关的公网出口，不是内网地址 |
| 公网 IP 经常变化、移动网络或多终端 | 账密认证通常更方便 | 凭证应妥善保存，不要写进公开日志或截图 |
| 第三方工具只支持 Host / Port / User / Pass | 账密认证 | 按照工具要求分别填写字段，不要随意拼接代理 URL |
| 需要批量生成多组代理配置 | 按后台当前支持的提取 / 批量导出方式处理 | 不同产品的字段和格式可能不同，以当前后台为准 |
如果使用白名单，最常见的错误是把 192.168.x.x、10.x.x.x 等内网地址填进去。真正需要核对的是代理网关看到的公网来源地址；云 NAT、办公网络出口或前置代理都可能改变这个地址。
四、922 用户怎么重新配置指纹浏览器？
指纹浏览器迁移时，不需要继续寻找“922 客户端端口”。核心是把当前代理产品提供的协议、Host、Port、Username 和 Password 填入浏览器的自定义代理区域，然后执行连通性检查。
- 在指纹浏览器中新建或编辑一个环境。
- 代理方式选择“自定义代理”或同类入口。
- 代理协议按照当前端点实际支持情况选择，不要因为旧客户端使用某一种协议就直接照搬。
- 填写后台提供的 Host 和 Port。
- 如使用账密认证，分别填写 Username 和 Password；如使用来源 IP 白名单，则先确认当前公网出口已经加入白名单。
- 点击“检查代理”或同类功能，确认连接成功并核对最终出口地区。
AdsPower 只是示例。BitBrowser、HubStudio 等工具的字段名称可能略有不同，但迁移逻辑相同：不要再填写旧的本地端口，而是让浏览器直接使用新的代理端点和认证方式。
五、原来的 127.0.0.1 代码怎么办？
如果原来的 Python、Node.js 或其他程序连接的是 127.0.0.1:5000 一类本地端口，迁移后通常不需要重写业务逻辑，但必须重新检查代理协议、Host、Port、认证、DNS、环境变量和 Session。
这篇只保留迁移判断，不再重复完整代码教程。Python Requests、Node.js、环境变量和最小请求怎么改，可以直接查看 从本地代理迁移到远程代理：代码与网络配置迁移指南。
如果最小脚本可以正常连接，而业务程序仍然失败，优先检查 HTTP_PROXY、HTTPS_PROXY、NO_PROXY、自定义 Agent、容器环境变量以及旧代理客户端是否仍在后台接管流量。
六、原来长期使用同一个 IP，迁移后怎么选？
1. 只需要一个任务周期内保持出口
如果你的需求是同一个任务、会话或一段连续操作期间尽量保持同一出口，应优先查看当前动态住宅或长效产品支持的粘性会话规则。具体保持时长、参数格式和可用范围应以当前后台和产品文档为准，不建议沿用旧文章中的固定时长参数。
2. 需要长期固定公网地址
如果业务真正需要长期固定的出口地址，再考虑 静态住宅 IP 等固定出口产品。选择前应确认目标地区、使用周期、认证方式和续费规则，而不是只根据“静态”两个字判断是否适合。
七、迁移完成后怎么检查是否成功？
“连接成功”只是第一步。迁移完成后建议至少检查下面四项：
- 代理端点：确认程序或浏览器实际连接的已经是新的 Host 和 Port，而不是旧的
127.0.0.1。 - 认证：确认账密或白名单已经真正生效，没有继续读取旧凭证。
- 最终出口：检查公网 IP 和地区是否符合当前配置。
- 会话行为：如果需要保持或轮换出口，连续请求确认实际行为符合预期。
如果浏览器测试成功但业务程序失败，问题通常已经从“代理不可用”缩小到程序自身配置；如果多个客户端都无法连接，则应回到代理端点、认证和网络环境重新排查。
八、922 S5 迁移常见问题
1. 922 S5 原来的本地端口为什么不能直接继续用？
因为 127.0.0.1 和旧端口指向的是本机上运行的 922 客户端。停止使用旧客户端后，这个本地监听端口就不再代表新的代理服务，需要改成当前代理提供的远程端点。
2. 迁移后应该选 IP 白名单还是账号密码认证？
固定服务器或固定公网出口可以考虑白名单；公网 IP 经常变化、多终端或第三方工具场景，账密认证通常更方便。最终仍要看当前产品和客户端支持的认证方式。
3. 为什么指纹浏览器显示代理连接失败？
先核对协议、Host、Port 和认证信息，再检查是否仍然填写了旧的 127.0.0.1。如果使用白名单，还要确认浏览器所在网络的实际公网出口已经加入允许列表。
4. 原来 922 能保持一段时间的 IP，迁移后怎么办？
先区分你需要的是“一个任务期间保持出口”还是“长期固定公网地址”。前者查看粘性会话或长效方案，后者再考虑静态住宅等固定出口产品，具体规则以当前产品为准。
5. 原来的 Python / Node.js 代码需要重写吗？
通常业务逻辑不用重写，但代理地址、认证、环境变量、DNS 和 Session 可能需要调整。代码如果封装得比较集中，迁移改动会更小。
6. 怎么确认迁移后已经使用新的代理出口？
从实际运行任务的同一台机器、容器或浏览器环境发起测试，核对当前代理 Host / Port、最终公网 IP、地区以及会话行为。不要只看后台配置是否保存成功。
下一步你可以做什么
先列出旧环境中所有与 922 S5 有关的本地端口、浏览器配置、脚本和环境变量，再逐项替换并验证。不要一次性同时改协议、账号、Session 和业务逻辑；每次只调整一个变量，更容易判断迁移失败发生在哪一层。
