高并发数据采集：隧道代理池架构设计与实现

本教程仅限于学术探讨，也没有专门针对某个网站而编写，禁止用于非法用途、商业活动、恶意滥用技术等，否则后果自负。观看则同意此约定。如有侵权，请告知删除，谢谢！

本项目为开源网络工具，仅用于学习、研究及合法的网络测试用途。

作者不鼓励也不支持将本软件用于任何违法行为，包括但不限于
绕过网络限制、未授权访问或违反所在国家或地区法律法规的行为。

使用者在使用本软件时，应自行确保其行为符合所在司法辖区的
相关法律法规。因使用本软件所产生的任何法律责任或后果，
均由使用者自行承担，与作者无关。

若您不同意上述声明，请勿使用本软件。

文章目录

概要：

[1. 接入简单](#1. 接入简单)

[2. 高可用性](#2. 高可用性)

[3. 自定义换 IP 策略](#3. 自定义换 IP 策略)

[4. 稳定弹性并发](#4. 稳定弹性并发)

[5. 支持多协议](#5. 支持多协议)

三、隧道代理适用场景

[📌 企业级数据采集](#📌 企业级数据采集)

[📌 大规模并发访问](#📌 大规模并发访问)

[📌 系统压力测试](#📌 系统压力测试)

[📌 区域性访问](#📌 区域性访问)

[四、隧道代理与传统 API 代理对比](#四、隧道代理与传统 API 代理对比)

五、隧道代理使用注意事项

六、总结

[代理池技术选型：Redis + RediSearch vs Elasticsearch](#代理池技术选型：Redis + RediSearch vs Elasticsearch)

[一、Redis + RediSearch](#一、Redis + RediSearch)

二、Elasticsearch

[三、性能对比 & 总结](#三、性能对比 & 总结)

整体架构流程

技术名词解释

[RediSearch 使用指南](#RediSearch 使用指南)

[一、RediSearch 简介](#一、RediSearch 简介)

二、RediSearch的安装&使用

三、官方文档资源

技术实现细节

[📘 官方 SOCKS5 协议规范（RFC 1928）](#📘 官方 SOCKS5 协议规范（RFC 1928）)

[1. servers.go 总入口分发器（详情请见socks5.go）](#1. servers.go 总入口分发器（详情请见socks5.go）)

[2. HTTP/HTTPS 分支关键流程](#2. HTTP/HTTPS 分支关键流程)

[2.1 协议识别（protocol()）](#2.1 协议识别（protocol()）)

[2.2 鉴权解析（extractBasicAuthFromHeader）](#2.2 鉴权解析（extractBasicAuthFromHeader）)

[2.3 业务路由](#2.3 业务路由)

[3. SOCKS5 主流程](#3. SOCKS5 主流程)

[4. SOCKS5 逐字节流解析](#4. SOCKS5 逐字节流解析)

[阶段 A：方法协商（Method Negotiation）](#阶段 A：方法协商（Method Negotiation）)

[阶段 B：用户名密码认证（RFC 1929）](#阶段 B：用户名密码认证（RFC 1929）)

[阶段 C：CONNECT 请求（目标地址）](#阶段 C：CONNECT 请求（目标地址）)

[阶段 D：TCP 转发（隧道阶段）](#阶段 D：TCP 转发（隧道阶段）)

[5. 二级 SOCKS5 代理链路](#5. 二级 SOCKS5 代理链路)

[6. 排障建议](#6. 排障建议)

[7. 两个字总结](#7. 两个字总结)

[8.HTTP & HTTPS](#8.HTTP & HTTPS)

小结

概要：

隧道代理全面解析：原理、优势与应用场景

在做数据采集、接口对接、系统稳定访问等业务时，代理IP几乎是必备工具。相比于传统每次单独获取 IP 的方式，隧道代理（Tunnel Proxy） 提供了一种更稳定、智能和省心的代理接入方式。本文将从原理、特点、优势及典型使用场景进行全面讲解

一、什么是隧道代理

隧道代理是一种特殊的动态代理服务，它通过在客户端和目标服务器之间建立一个固定的隧道通道，由服务端自动管理和切换底层代理 IP，从而实现智能调度和高可用访问。用户只需配置一个固定入口地址和端口，无需自行管理复杂的IP池。

与传统的 API 提取代理不同，隧道代理不是每次请求单独获取 IP，而是通过一个长期连接入口让后端自动调度可用代理 IP，有效简化了使用流程。

隧道代理核心原理

固定入口：客户只需配置一个固定的隧道代理地址和端口即可持续使用，无需频繁更换 IP。
IP自动调度：服务端自动从高质量 IP 池中选择可用 IP 并定期按策略切换。
弹性并发：支持并发控制和带宽弹性调整，满足高并发访问。
协议兼容：通常支持 HTTP/HTTPS 和 SOCKS5 等多种代理协议，适配多种业务需求。

简单理解就是：你只需设置一次代理入口地址，后端自动负责 IP 的分配、检测和轮换，大大降低了开发维护成本。

二、隧道代理的优势

隧道代理与普通代理池相比，在企业级使用中具有以下显著优势：

1. 接入简单

用户只需要一个固定代理地址和端口，无需通过 API 提取和维护 IP 池，极大简化了程序逻辑。

2. 高可用性

优质的隧道代理服务商在后台维护百万级别的活跃 IP 池，并对可用性进行实时检测，提升请求成功率。

3. 自定义换 IP 策略

支持按请求、按时间间隔等多种方式切换 IP，用户可以根据业务节奏灵活设置。

4. 稳定弹性并发

弹性并发控制机制允许短时间内突破并发限制，大幅提升并发访问能力，适配大规模任务。

5. 支持多协议

同时兼容 HTTP、HTTPS 和 SOCKS5 等协议，使代理在不同网络场景下都能使用。

三、隧道代理适用场景

隧道代理并非适合所有场景，而是更偏重长期运行、高并发和稳定性要求较高的业务。典型场景包括：

📌 企业级数据采集

需要持续抓取目标站点数据，且数据量大、访问频次高。

📌 大规模并发访问

多进程、多设备同时执行任务，对代理池并发性能要求高。

📌 系统压力测试

需要模拟真实用户行为进行压力测试，对稳定性要求较高。

📌 区域性访问

需要模拟不同省市、不同运营商 IP 访问目标服务。

此外，在 长期稳定性、隐私保护和网络匿名性 等方面，隧道代理也表现优于简单的代理获取方式。

四、隧道代理与传统 API 代理对比

特性	隧道代理	API 提取代理
入口方式	固定入口地址	每次调用接口获取 IP
配置复杂度	配置一次即可	需持续管理 API 调用
并发控制	弹性并发支持	受接口调用限制
IP 管理	后端自动调度	前端自行维护 IP 池
适合任务	长期稳定运行	灵活短期任务
稳定性	高	取决于 IP 调用成功率

总体来说，若项目对稳定性和持续性要求高，隧道代理更适合；若是短期、变动频繁的任务，API 代理更灵活

五、隧道代理使用注意事项

🔹 换 IP 策略需根据业务设定 ：如果是登录状态保持或浏览渲染类任务，不建议每次请求都更换 IP。

🔹 并发和带宽限制 ：不同套餐有不同的并发数和带宽上限，要根据实际需求选型。

🔹 协议类型：HTTP/HTTPS 和 SOCKS5 的支持程度会决定适应业务的灵活性。

六、总结

隧道代理通过固定入口、智能调度和多协议支持，使代理 IP 的使用变得更加简单和高效。对于需要长期运行、高并发访问和稳定业务成功率 的场景，它是比传统 API 代理更优的选择。

代理池技术选型：Redis + RediSearch vs Elasticsearch

在构建高性能代理池时，如何选择合适的存储和查询方案非常关键。本文从性能、扩展性、适用场景等角度对 Redis + RediSearch 与 Elasticsearch 进行对比分析。

一、Redis + RediSearch

类别	内容
优点	高性能：Redis 是内存数据库，读写性能非常高，适合高并发访问场景
优点	简单高效：通过 RediSearch 可以实现多条件过滤（如国家、ISP、端口等）
优点	轻量级：适合中等规模的数据量（几百万条记录）
缺点	内存消耗：存储大量数据（几百万条代理）会占用较多内存
缺点	水平扩展困难：虽然 Redis 支持集群，但当数据量极大时可能会遇到内存瓶颈，水平扩展较复杂
适用场景	小到中等规模的数据量，且需要非常高的查询性能和高并发访问时，Redis + RediSearch 是理想选择
推荐操作	使用 RediSearch 支持复杂查询（如按国家、ISP、端口等过滤）
推荐操作	高并发查询时，可以使用 Redis Pipeline 批量获取代理 IP，提高效率

二、Elasticsearch

类别	内容
优点	分布式架构：适合海量数据场景，能够轻松扩展
优点	丰富的查询功能：支持复杂查询、条件过滤、聚合等
优点	随机查询支持：原生支持 random_score，可基于字段或随机种子进行随机查询
缺点	性能稍逊：与 Redis 相比，写入性能较低，尤其在高并发写入时
缺点	硬件消耗高：需要更多硬件资源（内存、CPU、存储），特别是高可用和扩展性场景
适用场景	大规模数据量（上千万条记录），需要支持复杂查询和高并发查询，并且有分布式扩展需求

三、性能对比 & 总结

特性	Redis + RediSearch	Elasticsearch
写入性能	极快（内存存储）	较慢（基于磁盘存储）
读取性能	极快（内存存储）	稍逊，但支持大规模查询
查询复杂度	支持基本多条件过滤	支持复杂查询、聚合和过滤
数据量	小到中等规模（百万级）	大规模（千万级以上）
水平扩展性	受限于内存，水平扩展较困难	分布式设计，水平扩展容易
硬件要求	较低，但需足够内存	高，需要较多内存、CPU、存储
[性能对比]

类别	Redis + RediSearch	Elasticsearch
总结缺点	受内存限制，水平扩展困难	性能略逊，硬件成本高
使用场景推荐	小到中等规模代理池（百万条以内），高性能、高并发查询	海量代理池（千万条以上），复杂查询、高并发、分布式扩展需求
[推荐使用场景]

整体架构流程

|-----------------------------------------------------|
| - 入口：`cmd/main.go` 创建 `ProxyServer`，监听连接。 |
| - 每条连接：`services.NewHandleClient` 先识别协议，再做鉴权。 |
| - 业务分流：`GET /ip` 返回代理信息；HTTP/HTTPS/SOCKS5 走各自处理器。 |
| - 隧道模式：通过 `GetProxy` 从 Redis 代理池取二级代理。 |
| - HTTPS CONNECT：建立隧道成功后使用 `ForwardData` 双向传输。 |
| 附加功能：隧道模式自动安装 RediSearch ，普通代理模式默认直接转发 |
[快速说明(一分钟) && 项目开源地址： https://github.com/jaygarage/GoodPeopleLibraryhttps://github.com/jaygarage/RapidTunnel]

XML 复制代码

D:\JAY\TUNNELPROXY
|   .gitignore                 # Git 忽略文件
|   makefile                    # Linux 中程序打包命令：make build
|   README.md                   # 项目说明文档
|       
+---cmd
|       main.go                 # 程序入口
|       main.sh                 # 启动脚本
|       
+---proxy
|   |   AgentPools.go           # 代理池管理
|   |   BasicAuth.go            # 基础认证处理
|   |   forward_data.go         # 数据转发逻辑
|   |   http.go                 # HTTP 代理处理
|   |   https.go                # HTTPS 代理处理
|   |   types.go                # 结构体和类型定义
|   |   
|   \---socks
|           auth.go             # SOCKS 认证
|           init.go             # 初始化逻辑
|           socks4.go           # SOCKS4 功能（弃用）
|           socks4SecondaryProxy.go # SOCKS4 次级代理（弃用）
|           socks5.go           # SOCKS5 协议实现
|           socks5SecondaryProxy.go # SOCKS5 次级代理
|           
+---services
|       servers.go              # 服务器相关服务逻辑
|       
+---utils
|   +---abs_project_path
|   |       get_abs_project_path.go   # 获取项目绝对路径工具
|   |       
|   +---install_redis
|   |       install_redis.go          # Redis 安装工具
|   |       install_redis_test.go     # Redis 工具测试文件
|   |       
|   +---logrus
|   |       logrus.go                 # 日志封装工具
|   |       logrus_test.go            # 日志工具测试文件
|   |       
|   +---redisclient
|   |       redisclient.go            # Redis 客户端封装
|   |       redis_test.go             # Redis 客户端测试
|   |       
|   \---settings
|           settings.go              # 配置管理

技术名词解释

RediSearch 使用指南

一、RediSearch 简介

RediSearch 是 Redis 的模块化扩展，用于在 Redis 中提供全文搜索、二级索引和复杂查询能力。它不仅能对字符串进行全文搜索，还支持数字、地理位置和标签等字段的过滤，非常适合需要高性能查询的场景。

二、RediSearch的安装&使用

由于集成到了隧道代理程序中，所以我们不需要安装了

1.创建索引：FT.CREATE proxy_pools_idx ON HASH PREFIX 1 "proxy_pools:" SCHEMA port TAG SORTABLE source TAG SORTABLE country TAG SORTABLE region TAG SORTABLE city TAG SORTABLE isp TAG SORTABLE other_info TAG SORTABLE expiration_time NUMERIC SORTABLE

添加文档：HSET proxy_pools:127.0.0.1 account "test" password "test123456test" source "test" machine_code "test" internet_ip "127.0.0.1" intranet_ip "127.0.0.1" port "81" country "cn" region "中国" city "test" other_info "" isp "unknown" expiration_time 1710502843; EXPIRE proxy_pools:127.0.0.1 100000

3.条件搜索（标签、数字范围）：FT.SEARCH idx:proxy "@country:{CN} @port:[8000 9000]"

4.聚合查询：FT.AGGREGATE idx:proxy "*" GROUPBY 1 @country REDUCE COUNT 0 AS count

5.删除索引：FT.DROPINDEX proxy_pools_idx

三、官方文档资源

🔗 RediSearch 官方 GitHub 仓库（源码 + 文档链接）https://github.com/RediSearch/RediSearch?utm_source=chatgpt.com 🔗 Redis 官方搜索与查询文档（最新 2.x RediSearch）https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/search/?utm_source=chatgpt.com 🔗 Redis Query Engine（RediSearch）综合文档https://redis.io/docs/latest/develop/ai/search-and-query/?utm_source=chatgpt.com

技术实现细节

本文将带你梳理一个 Go 语言实现的 TCP 代理项目的核心逻辑，从 servers.go 的入口分发器，到 HTTP/HTTPS 与 SOCKS5 的详细协议流程，再到二级 SOCKS5 代理链路的实现。

📘 官方 SOCKS5 协议规范（RFC 1928）

👉 RFC 1928 -- SOCKS Protocol Version 5（纯文本版）https://www.rfc-editor.org/rfc/rfc1928.txt 👉 RFC 1928 -- HTML 格式规范https://datatracker.ietf.org/doc/html/rfc1928?utm_source=chatgpt.com 👉 RFC 1929 -- Username/Password Authentication for SOCKS V5https://www.rfc-editor.org/rfc/rfc1929.txt

跟多的官方文档自己找了，记不清了，我当时是参考了挺多项目的，像 GOST 等项目都是有看的

1. `servers.go` 总入口分发器（详情请见socks5.go）

在 TCP 层接入后的每条连接都会走 services.NewHandleClient(conn)，核心流程如下：

步骤	描述
1	创建 `bufio.Reader` 以便后续读取首包数据
2	调用 `protocol()` 识别协议
3	分流到不同处理器： • SOCKS5 → `socks.HandleSocks5` • HTTP/HTTPS → `handlerHttpAndHttpsServer`
4	未识别协议则记录告警并退出

可以把它理解为 L4 接入后的协议路由器，快速分流不同类型的连接。

2. HTTP/HTTPS 分支关键流程

2.1 协议识别（protocol()）

首字节判断：
- 0x05 → SOCKS5
- 0x04 → SOCKS4（当前未启用）
首行前缀判断：
- CONNECT → HTTPS 隧道请求
- GET / POST → HTTP 请求

这是轻量的"首字节 + 首行前缀"策略，速度快，适合入口快速分流。

2.2 鉴权解析（extractBasicAuthFromHeader）

支持 Proxy-Authorization 或 Authorization 的 Basic 认证
Base64 解码后按 username[:params]:password 格式解析
用户名可以携带查询参数：username|k=v&k2=v2 → 转成 QueryParams
认证失败统一返回 407 Proxy Authentication Required

2.3 业务路由

路径	处理逻辑
`GET /ip`	从代理池选代理并返回 JSON
`CONNECT`	HTTPS 隧道处理
其他方法	HTTP 转发处理

3. SOCKS5 主流程

实现分布在 proxy/socks/socks5.go、auth.go 和 socks5SecondaryProxy.go：

方法协商（客户端声明支持的认证方式）
服务器选择用户名/密码认证（0x02）
客户端发送用户名与密码
服务端调用 proxy.BasicAuth 验证
认证成功后客户端发送 CONNECT 目标地址
代理直连目标或通过二级 SOCKS5 代理建链
返回成功状态后进入双向转发 ForwardData

4. SOCKS5 逐字节流解析

阶段 A：方法协商（Method Negotiation）

客户端发给代理的请求格式（RFC 1928）：

VER：版本号，0x05

NMETHODS：客户端支持的认证方法数量

METHODS：每个字节表示一种方法（0x00=无认证，0x02=用户名密码认证）

|-----|----------|---------|
| VER | NMETHODS | METHODS |
| 1 | 1 | 1~255 |
[请求格式]

示例（只支持用户名密码）：

05 01 02 // 客户端只支持用户名密码认证

代理 → 客户端

05 02 // 选择用户名密码认证方式

|-----|--------|
| VER | METHOD |
| 1 | 1 |
[代理选择返回格式]

阶段 B：用户名密码认证（RFC 1929）

客户端 → 代理

VER：子协商版本号，0x01

ULEN：用户名长度

UNAME：用户名

PLEN：密码长度

PASSWD：密码

|-----|------|--------|------|--------|
| VER | ULEN | UNAME | PLEN | PASSWD |
| 1 | 1 | 1~255 | 1 | 1~255 |

示例（用户名 jay，密码 test1234）：

01 03 6a 61 79 08 74 65 73 74 31 32 33 34

代理 → 客户端

01 00 // 认证成功

|-----|--------|
| VER | METHOD |
| 1 | 1 |
[认证结果]

用户名支持携带筛选参数： username|country=HK&isp=aws

阶段 C：CONNECT 请求（目标地址）

客户端 → 代理

+----+-----+-----+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-----+------+----------+----------+

VER：0x05

CMD：命令码（0x01=CONNECT，0x02=BIND，0x03=UDP ASSOCIATE）

RSV：保留字节 0x00

ATYP：目标地址类型（0x01=IPv4，0x03=域名，0x04=IPv6）

DST.ADDR：目标地址，长度取决于 ATYP

DST.PORT：目标端口，大端序（2 字节）

示例 1：IPv4 1.2.3.4:80

05 01 00 01 01 02 03 04 00 50

ATYP=0x01 → IPv4

DST.ADDR=01 02 03 04

DST.PORT=0x0050 → 80

示例 2：域名 example.com:443

05 01 00 03 0b 65 78 61 6d 70 6c 65 2e 63 6f 6d 01 bb

ATYP=0x03 → 域名

DST.ADDR长度=0x0b=11，内容=example.com

DST.PORT=0x01bb → 443

代理 → 客户端

成功示例：

+----+-----+-----+------+----------+----------+

|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |

+----+-----+-----+------+----------+----------+

REP：0x00 = 成功，其余失败码参考 RFC

BND.ADDR / BND.PORT：代理端绑定地址

返回绑定地址后进入双向转发。

阶段 D：TCP 转发（隧道阶段）

CONNECT 成功后，SOCKS5 协议完成，进入纯 TCP 字节流透传阶段：
客户端发的数据直接转发到目标
目标返回的数据直接转发给客户端
HTTPS、HTTP 或任意 TCP 流量都在此隧道中进行

阶段	对应函数 / 方法
方法协商	`socks.HandleSocks5` → `readMethods()` / `chooseAuth()`
用户名密码认证	`socks.HandleSocks5` → `auth.go` → `BasicAuth()`
CONNECT 请求	`socks.HandleSocks5` → `handleConnect()`
TCP 转发	`socks.ForwardData()`

5. 二级 SOCKS5 代理链路

当前代理可选择不直连目标，而是通过二级代理建立隧道

链路：

Client → 本代理 → 二级代理 → 目标站点

流程：

从 Redis 代理池取二级 SOCKS5
与二级代理完成方法协商和用户名密码认证
向二级代理发送 CONNECT 请求到最终目标
成功后通过 ForwardData 转发客户端数据

6. 排障建议

阶段	排查关键点
A	方法协商是否收到 `05 02`
B	认证是否返回 `01 00`
C	CONNECT 是否成功 (`REP=0x00`)
隧道模式	二级代理可达性和账号密码正确性
业务失败	目标服务或上层协议（TLS/SNI/证书）问题

7. 两个字总结

servers.go：总入口分发器（协议识别 + HTTP 鉴权 + 业务路由）
SOCKS5：标准三段式（方法协商 → 用户密码认证 → CONNECT 建连）
建连成功后：纯 TCP 字节透传，协议无关

8.HTTP & HTTPS

块	实现步骤 / 核心逻辑	技术关键点 / 说明
HTTP 代理 (`HandleHTTPProxy`)	1. 使用 `http.ReadRequest` 解析完整请求行、Header、Body 2. Basic Auth 鉴权通过后进入 HTTP 处理分支（非 CONNECT 请求） 3. 构建 `http.Transport` 并通过 `RoundTrip(req)` 转发请求 4. 隧道模式与普通模式区分：• 普通模式：直接 TCP 连接目标主机• 隧道模式：通过 `proxy.GetProxy` 从 Redis/RediSearch 代理池选取二级代理，再设置 `Transport.Proxy` 5. 异常处理：捕获网络错误、HTTP 4xx/5xx 返回自定义响应	HTTP 为应用层请求级转发，可见完整 URL、Header、Body。关注请求超时、连接复用和 Header 注入等实现细节。
HTTPS 代理 (`HandleHTTPSProxy` + CONNECT)	1. 客户端发 `CONNECT host:port` 请求建立 TCP 隧道 2. 代理处理 TCP 层隧道：• 普通模式：直接 Dial 目标 TCP• 隧道模式：先 Dial 二级代理，再发 `CONNECT target` 3. 返回 `200 Connection Established` 表示隧道就绪 4. 调用 `ForwardData` 双向拷贝字节流（TLS 握手、加密流透传） 5. 二级代理异常透传：非 200 状态直接返回客户端	HTTPS 隧道是 TCP 层转发，代理无法解密内容，只能获取目标地址、端口和握手状态。关注隧道稳定性、流量复制效率、半开连接处理。
HTTP vs HTTPS 核心区别	1.层级差异：HTTP 为请求级，HTTPS 为连接级隧道 2.可观测性：HTTP 可解析业务内容，HTTPS 仅可观测 SNI/Host 元数据 3.错误发生位置：HTTP 在 `RoundTrip`，HTTPS 在 CONNECT/TCP 阶段 4. 性能关注：HTTP 优化连接复用和请求超时，HTTPS 优化隧道稳定性和字节流拷贝效率	理解协议层级差异，有助于调试连接失败、超时和代理调度问题。
排障建议	1.HTTP 失败：检查二级代理可用性、RoundTrip 错误类型、DNS 解析、端口可达性 2.HTTPS 失败：优先查看 CONNECT 返回码是否为 200，二级代理透传响应 3.偶发超时：关注 `IdleConnTimeout`、TLSHandshakeTimeout、``ExpectContinueTimeout、网络 RTT 4.鉴权问题：检查 Authorization 格式和账号密码编码（含特殊字符转义）	排障思路：按协议层级逐步排查，从代理获取、隧道建立到 Transport 层转发性能，关注 TCP 半开连接和 TLS 握手异常。

[http&https]

小结

复制代码

我这边的 go 版本是 1.26.1执行以下命令配置好GO环境依赖

复制代码

- **安装缺失环境命令**
  - 初始化: go mod init liveoddsscraper
    - 自动安装缺失环境: go mod tidy

1.在此之前我们安装好了服务器的RediSearch了并准备好了环境依赖，我们先启动两个程序，一个80端口作为隧道转发，一个81接口作为普通代理模式

2.我们先测试下普通的直连代理，访问百度也是没有任何问题的

3.再来试试隧道代理的功能怎么样吧，我们需要先在redis中添加一个账号，账号密码就叫test

4.存储刚刚创建的81端口代理到redis代理池中

5.如图1隧道代理正常进入的，从代理池中拿到代理IP，非常丝滑的访问了百度

6.我们来试试线上效果吧，跟三方代理功能几乎一致，也是支持过期时间、区域的过滤的哈纳斯~

到最后呢，基本上都可以满足个人代理使用的.

那我们下期再见咯~ 拜拜勒您~

本项目为开源网络工具，仅用于学习、研究及合法的网络测试用途。

作者不鼓励也不支持将本软件用于任何违法行为，包括但不限于
绕过网络限制、未授权访问或违反所在国家或地区法律法规的行为。

使用者在使用本软件时，应自行确保其行为符合所在司法辖区的
相关法律法规。因使用本软件所产生的任何法律责任或后果，
均由使用者自行承担，与作者无关。

若您不同意上述声明，请勿使用本软件。