统一代理网关

统一代理网关

大类
CloudResource
Util
技术标签
环境增强
优先级
Medium
状态
In Progress
开始日期
May 23, 2025
最后更新
Jun 23, 2025
Public
初版架构设计Vibe第一轮优化多provider与多dialer处理问题其他细节设计指示系统总体连接优化逻辑Vibe 第二轮优化第二版架构设计第二轮重构第三轮Vibe code

初版架构设计

  • 架构：
inbound ---> router ---> connector
                     |
                  provider
  • inbound：解析传入请求
    • 监听http/socks5并中继
    • 传入的用户名:密码格式为K1-V1-K2-V2-K3-V3...:PASSWORD，解析用户名的K-V结构并相应提供给router
      • 用户名长度是否有限制？
  • router：管理ip、驱动健康检查
    • 接收KV参数
      • user用于鉴权 & 记录
      • sess用于区分不同ip，同session ip自动固定不变
      • country、state、city三级分类，得到目标连接位置
        • 支持正则匹配5
    • 自动健康检查，并接收KV参数timeo，健康检查超过timeo秒后没有成功自动切换ip
    • （可选）接入scamalytics，保证ip fraud score小于指定值（这个可以通过我的另一个api http://ip2map.traefik.conoha-jp.misty.moe/addr）
  • provider：统一抽象国内外各个代理提供商
    • 提供原始dialer供router使用
    • 针对国内的api提取类代理供应商，手动实现user-country-state-city-sess接口
    • 支持通过 sslip.io 等服务通过域名连接绕过提供商黑名单
    • （可选）统一不同供应商之间国家和地区命名
  • connector：针对dialer提供连接优化
    • 自动连接重试：
      • 当dialer socks/http握手失败时（返回错误或者超时），主动重试
      • 同步汇报连接状态
    • 高级自动连接重试：握手成功，但是请求失败时，自动重启连接
      • 嗅探HTTP请求包（可忽略http2）
      • 嗅探TLS ClientHello

Vibe第一轮优化

 

多provider与多dialer处理问题

  • 实际中，肯定存在多个provider的情况，不同provider之间：
    • 支持的country不同
    • ip存活时间不同
    • 测活方式不同
  • 场景
    • 隧道代理：
      • 健康检查 + 简单preheat
        • 但是得考虑流量，应该严格限制健康检查的频率
      • ip变化感知：
        • 主动去请求ip api来获取ip变化的情况
        • 如果ip变化，自动提示上层api
    • 直连代理
      • 健康检查 + 自动ip过期 + 自动preheating下一个连接
        • 国内的代理池ip会自动在一定时间后失效，应该主动去请求新的ip
        • 可能ip要持续拉取，不能简单on-demand
  • 梳理功能需求
    • 健康检查本身肯定是provider提供的功能
    • preheat和ip过期本质上两者通用
      • 限制流量和不限制的流量的通过健康检查的频率和preheat的激进程度来区分
    • ip变化这个可以通过在provider中加获取ip接口来同时支持两类代理
  • 实现上有两种思路
    • 一种是在每个provider里面做pool，这样可以支持不同类型的代理（例如隧道代理和直连代理）
      • 如果这么设计，那么provider应该提供一个interface，允许router进行start preheat、end preheat、单独health check的功能
      • 这样的话，是否能够保证连接的稳定性？
    • 一种是在router里面进行health check，这样也可以支持不同类型的代理那么就需要考虑不同类型的代理health check的策略
    • 在每个provider里面单独做似乎并没有更大的优势，所以选择集成在route里面
  • 最终AI prompt
    • 用户追加指示，需要完整重构多个provider、多个dialer中选取时的策略
      • 多个provider之间的选择继续沿用当前的round-robin等策略，一个provider获取dialer失败时自动通过其他provider进行获取
      • 删除当前的geo选择策略，重新设计geo相关逻辑。选择provider/dialer时，严禁代理池本身根据country-state-city直接筛选dialer，country-state-city参数必须直接传入provider，完全由provider控制
    • 用户追加指示，改进router的连接池与健康检查功能
      • router需要维护连接池，连接池需要与country-state-city联动，不同的country-state-city之间不能共享dialer
      • 在连接成功发起后，即创建或复用已有的连接池，连接池中的连接数量应维持在可配置的数量
      • 健康检查的最终执行者应为各个provider模块，由provider提供健康检查的相关interface
 

其他细节设计指示

  • inbound:
    • socks5和http的auth部分、param解析代码应该共用代码
    • socks5和http的s.router.Route + s.connector.Connect的创建连接代码也应该做进一层封装以共用代码
  • router:
    • 更正router中的sess调用方式，sess实际上为连接时params的可选项，无法单独使用，例如user-A-country-B-city-C为每次连接随机更新ip，而user-A-country-B-city-C-sess-XXX则为保持同sess ip不变
    • router的session为自动管理，无需用户主动释放sess，而是在一个session超过配置的时间后自动回收
  • 跨inbound、router、connector等模块间传递的net.Conn应该被包装为一个通用interface以支持更多高级功能
 

系统总体连接优化逻辑

  • 失效连接自动failover
    • 自动检测失效连接：tcp层流量连续40s无上下行流量自动关闭连接
    • 弱网并发连接：
      • TLS连接：TLS握手ClientHello后1s内失败同时使用多个备用dialer进行重发
      • HTTP连接（目前版本暂时不做）：嗅探连接中的每个http1 GET请求（http2或multipart等请求log后自动忽略对应连接后续请求）
        • http层连接池连接时同时创建多个backup连接发送HEAD /robots.txt请求，存活时间60s，但是保证每个host的总backup连接数小于配置值
        • 针对GET请求，超过30s无任何返回后自动重试至目标ip，后续目标ip接管连接
  • 按照之前指示连接池需要自动preheat，也需要自动关闭preheat。在所有相关连接均关闭后，preheat在1分钟后再关闭
    • router的接口需要增加允许限制新dialer为同一c段
 

Vibe 第二轮优化

  • connector
    • 目前连接优化的相关逻辑均位于router中，原计划应位于connector中
    • 连接优化的相关逻辑有可能需要动态获取新的dialer，因此需要让router为connector提供获取dialer的接口（而不是直接建立好的dialer）
    • AIPrompt：
        • 用户追加指示如下，通过knowledge记住如下需求的关键点：

1. 修改router与connector的接口，router应为connector提供获取dialer的interface

2. 整理目前位于connector和router中的连接优化相关代码， preheat连接池等逻辑应予以保留，而连接建立后的自动检测失效连接、弱网优化、failover等逻辑全部移动到connector包中

使用Task Manager配合Sequential Thinking正确安排任务流程并执行，无需询问用户确认
  • router：
      • 用户追加指示如下，通过knowledge记住如下需求的关键点：

1. 修改router与connector的接口，router应为connector提供获取dialer的interface

2. 整理目前位于connector和router中的连接优化相关代码， preheat连接池等逻辑应予以保留，而连接建立后的自动检测失效连接、弱网优化、failover等逻辑全部移动到connector包中

使用Task Manager配合Sequential Thinking正确安排任务流程并执行，无需询问用户确认
    • session管理部分未按照用户要求实现，对于属于同一个session的连接，默认情况下应直接共用connector，而不是重新执行route程序
 

第二版架构设计

  • 架构：
inbound ---> router ---> connector
                     |
                  provider
  • inbound：解析传入请求
    • 监听http/socks5并中继
    • 传入的用户名:密码格式为K1-V1-K2-V2-K3-V3...:PASSWORD，解析用户名的K-V结构并相应提供给router
    • socks5和http的auth部分、param解析代码应该共用代码
  • router：从provider获取dialer并进一步提供给connector，驱动健康检查preheat dialer pool，并是实现session管理
    • 接收KV参数
      • user用于鉴权 & 记录
      • sess用于区分不同ip，同session ip自动固定不变
      • country、state、city三级分类，得到目标连接位置
        • 地理相关的参数直接透传到provider中
    • session支持：同一个session返回相同的ip
      • 原理：使用相同session多次从router获取dialer时，对应的dialer的ip地址应保持不变（除非对应ip失效）
      • sess实际上为连接时params的可选项，无法单独使用，例如user-A-country-B-city-C为每次连接随机更新ip，而user-A-country-B-city-C-sess-XXX则为保持同sess ip不变
      • router的session为自动管理，无需用户主动释放sess，而是在一个session超过配置的时间后自动回收
    • dialer pool：自动进行健康检查提高连接成功率
      • 接收KV参数timeo配置健康检查超时时间
      • 连接池需要与country-state-city联动，不同的country-state-city之间不能共享dialer
      • 在连接成功发起后，即创建或复用已有的dialer池，dialer池中的数量应维持在可配置的数量
      • 健康检查的最终执行者应为各个provider模块，由provider提供健康检查的相关interface
    • route规则：
      • 多个provider之间使用round-robin等策略，一个provider获取dialer失败时自动通过其他provider进行获取
      • 选择provider/dialer时，严禁代理池本身根据country-state-city直接筛选dialer，country-state-city参数必须直接传入provider，完全由provider控制
    • 接入scamalytics，保证ip fraud score小于指定值
  • provider：统一抽象国内外各个代理提供商
    • 提供原始dialer供router使用
      • 这个dialer实际上在inbound、router、connector等模块间传递，应该被包装为一个通用interface以支持更多高级功能，能够获取当前dialer的description、统计信息、当前ip等
    • 针对国内的api提取类代理供应商，手动实现user-country-state-city-sess接口
    • 支持通过 sslip.io 等服务通过域名连接绕过提供商黑名单
    • （可选）统一不同供应商之间国家和地区命名
  • connector：针对dialer提供连接优化，支持连接失效时自动failover
    • 自动检测失效连接：tcp层流量连续40s无上下行流量自动关闭连接
    • 弱网并发连接：
      • 基于连接池实现，连接池需要自动preheat，也需要自动关闭preheat。在所有相关连接均关闭后，preheat在1分钟后再关闭
      • TLS连接：TLS握手ClientHello后1s内失败同时使用多个备用dialer进行重发
      • HTTP连接（目前版本暂时不做）：嗅探连接中的每个http1 GET请求（http2或multipart等请求log后自动忽略对应连接后续请求）
        • http层连接池连接时同时创建多个backup连接发送HEAD /robots.txt请求，存活时间60s，但是保证每个host的总backup连接数小于配置值
        • 针对GET请求，超过30s无任何返回后自动重试至目标ip，后续目标ip接管连接
prompt策略：
目前程序已经完成主体开发，需要进一步检查需求实现情况
你应该首先使用sequential think深入思考下面的需求，思考各个模块之间的交互关系并记录。随后等待用户指示

基于上面理解，利用taskmanager对每个大需求点创建任务进行追踪，task manager中记录的内容应与下面的原始需求每一个字完全一致，不得省略任何内容，完成后等待用户指示

请继续进行当前任务以及task manager中的所有任务，无需询问用户确认。你应该使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。
目前程序已经完成主体开发，正在进一步检查需求实现情况，在检查时，你应该无论大小认真检查全部需求点。每一个需求点的都应该有对应的testcase，同时要确保对应代码正确在各个模块中发挥作用，对于复杂的需求，你应该用Sequential Thinking深入思考该需求是否正确与各个模块之间联动。

第二轮重构

  • router和connector
用户增加重构要求:
- 创建 DialerFactory 函数类型，func () Dialer，用于沟通connector和router
- connector的初始化接口应从dialer字段修改为利用factory函数获取新的dialer
- 清理router的无用代码并更换为正确名称
  - router的route应返回dialerfactory
	- router中应仅包含health check和维护dialer pool和route相关代码，failover字样不应出现。
  - router中的pool不应分为多个，不使用country-state-city的连接实际上等效于字段为null的连接，因此删除额外代码

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:

- provider返回的dialer应完全被替换为EnhancedDialer

- provider中的HealthCheck等方法应转移至EnhancedDialer中

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:

- router中的ConnectionPool应完全删除，并改为实现基于country-state-city作为key的dialer pool
- router中的dialer pool需求如下：自动进行健康检查提高连接成功率
    - 接收KV参数timeo配置健康检查超时时间
    - 连接池需要与country-state-city联动，不同的country-state-city之间不能共享dialer
    - 在连接成功发起后，即创建或复用已有的dialer池，dialer池中的数量应维持在可配置的数量
    - 健康检查的最终执行者应为各个provider模块，由provider提供健康检查的相关interface
使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- router中的EnableAutoSessionManagement应始终为启用状态，session的Auto cleanup功能也同样是始终为开启状态，相应修改全部的代码
- session的逻辑与router高度耦合，不应该是独立的package，应当将现有session manager代码迁移回router并删除相关全局interface

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- router的locationDialerPool已经永远不为空，删除所有== nil的分支，并删除autoManaged字段
- logger模块应增加新方法func GetLoggerWithField(ctx, fields) (context.Context, *logger.Entry)，来替换全部模块中的logger.GetLogger(ctx).WithFields(...)，应该在函数起始时调用该方法将本func存储logger和新ctx，随后直接调用logger。同时，相关的通用的field应被整合到context中，而特殊分支的field则可以继续使用WithField

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户明确任务：
- 用户发现部分函数不需要对logger附加更多的field，但仍然存在大量的logger.GetLogger重复调用，用户要求对于该类函数，应在函数起始位置使用log变量存储获取到的logger，而不是多次调用

- 此前用户要求将logger.GetLogger替换为logger.GetLoggerWithField。logger.GetLoggerWithField应只在每个func开头处使用，对于函数内其他需要field的情况，你应综合分析对应函数对field的使用，将同一个函数内各个log相同的field抽取到函数开头的logger.GetLoggerWithField，而着其他field则直接在entry上使用WithField方法进行log即可。

使用Task Managert配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- router的locationDialerPool已经永远不为空，删除所有判断locationDialerPool是否为nil的分支。
- 现有dialer pool实现及调用均存在巨大问题。
	- router的dialer pool应当被深度使用，所有的router均应从dialer pool中获取
	- dialer pool本身应以特殊的cacheKey区分不同种类的dialer，cacheKey的实际内容应为country-state-city
	- router应当在获取dialerfactory时就初始化dialerpool中对应cacheKey的preheat工作，保证
  - 健康检查的最终执行者应为EnhancedDialer的HealthCheck方法

使用Task Managert配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 第一阶段：删除无用字段
  - 在所有包中删除ClientIP字段，并删除scamalytics相关逻辑
- 第二阶段，重构并拆分types.ProxyParams
  - inbound向router传入params时不应使用types.ProxyParams，而是应该使用最原始的map[string]interface{} (可以用RawProxyParams等名称包装)
  - 应该分层处理从inbound传来的raw param，并在参数名称上进行一定区分
  - 在inbound层，应当处理params中的user与password等信息，该信息不应传入router
  - 在router层，应当处理params中的session字段，该信息不应传入dialerpool
- 第三阶段，重构dialer pool
	- 在dialerpool中，修改之前的cacheKey规则，直接使用序列化后的params作为cacheKey，避免与params耦合
  

使用Task Managert配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 重构DialerPool和LocationDialerPool
	- 整体目标：去除LocationDialerPool，将preheat功能移动到DialerPool，而其他功能则移动到router
	- 第一阶段：将所有 LocationDialerPool 中和单个DialerPool关联的功能全部移动到DialerPool，尽可能精简化LocationDialerPool的功能
	- 第二阶段：将LocationDialerPool简化为仅有启动、停止、管理功能，然后将其更名为DialerPoolManager

使用Task Managert配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 修改重构DialerPoolManager
  - DialerPoolManager应仅管理DialerPool的创建与关闭，不应存储provider；provider应被DialerPool本身管理以增加灵活性。
  - 清理router残存的locationDialerPool字样
  - DialerPoolManager应使用ctx with cancel进行管理，避免出现各种后台goroutine无法退出的情况

使用Task Managert配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 修改重构DialerPoolManager
  - 严禁DialerPoolManager进行任何增加/删除Dialer的操作
  - DialerPoolManager的cacheKey应改为序列化后的params
  - DialerPool应存储provider和params

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 修改重构DialerPoolManager
  - 现在的cachekey使用的是LocationKey，将所有的LocationKey改为使用DialerParams，DialerPoolManager的pools map可以改为使用map[types.DialerParams]*DialerPool（注意key不要使用指针），并删除LocationKey

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个任务可以被拆分为多个小点时，你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 修改重构DialerPoolManager、DialerPool、Router
  - 重新规定DialerPoolManager的使用方法，router是目前唯一使用DialerPoolManager的位置，使用patter应当如下
	  ```
	  // 删除DialerPoolManager的GetDialer方法，dialer必须从pool中拿到。
	  // 同时GetPool也应该修改，当Pool不存在时应当自动创建pool，而不是需要用户手动CreatePool 
	  // 所有GetPool的原型均以下面的为准
	  pool, err := r.dialerPoolManager.GetPool(ctx, dialerParams, r.providers, r.selector)
	  // pool中有多个provider时，应该使用创建pool时使用的selector进行选择
	  dialer := pool.GetDialer(ctx)
	  ```
  - pool应当主动维持pool中dialer的数量，而不是在创建连接时lazily地调用createDialerIfNeeded进行创建

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 修改重构Router
  - 删除RouteWithSession方法，注意同时删除stat和相关testcase

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 重构Router的Session相关逻辑
	- 保留当前的SessionManager，但是需要修改其中的SessionInfo
	- SessionInfo中不需要保存当前使用的ProxyInfo，而是应当保存对应的Dialer和Provider
  - 当reuse现有session时，DialerFactory应当判断保存的dialer是否健康，健康时直接返回原有dialer，否则从pool中获取一个新的dialer（需要注意加锁，避免并发替换dialer）
  
使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 重构Router的Session相关逻辑和SessionManger
	- 任务阶段1：删除Session Manager的无用包装GetSessionWithDialer和SetSessionWithDialer
	- 任务阶段2：将现有的func (r *Router) Route() 方法返回的DialerFactory拆分为两个单独的命名函数分别处理有sess和无sess的情况，形如func (r *Router) getDialerFactoryWithSession(...) DialerFactory
	- 任务阶段3：完整删除getSessionDialer方法，整合到相应的getDialerFactoryXXX方法中
  
使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 删除Router中的legacy GetDialer(ctx context.Context, params *types.ProxyParams)方法
- Router内部的GetPool -> pool.GetDialer的模式统一替换为使用router的getDialerInternal()方法
  
使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 删除SessionManager中的redis store
- EnhancedDialer中增加GetProvider接口

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 删除SessionManager中的redis store
- EnhancedDialer中增加GetProvider接口

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
	继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- Router中的HealthCheck逻辑应完全位于DialerPool中，应当将performHealthChecks及其相关方法全部移动到DialerPool中，并通过maintainDialers自动触发。

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
	继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
用户增加重构要求:
- 进一步分割provider中的代码
	- 第一步：移动provider中所有和dialer相关的代码和test到provider下的dialer子包，（如http与socks5 dialer、blacklist bypass中的各种dialer等）
	- 第二步：创建provider下的mock子包，移动httpprovider和socks5provider到其中
	- 第三步：整合blacklist bypass和geo provider为一个example provider，并移动到单独的example子包中

使用Task Manager配合Sequential Thinking正确安排任务流程，当一个子任务过于复杂时（超过10个步骤时），你应该主动使用task manager规划子任务。由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。
	继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
 

第三轮Vibe code

重新设计EnhancedDialer的实现。当前的EnhancedDialer为interface，由多种不同的Dialer实现（HTTPDialer、Socks5Dialer、MockDialer、SSLIPBypassDialer等实现。
现在需要保留EnhancedDialer interface不变将这些Dialer中的部分功能呢统一实现
- EnhancedDialerImpl实现链式代理、SSLIP Bypass、Health Check、连接统计收集等接口，但不处理最终对外的代理连接。EnhancedDialerImpl应当接收一个interface参数，包含：
func ProxyConnect(ctx context.Context, parentDialer net.Dialer, network string, addr string) (net.Conn, err) // 接收前置的Dialer，并使用这个Dialer完成最终的代理连接。
func ProxyHealthCheck(...) ... // 只负责执行真正健康检查，健康检查的状态Cache则应该在EnhancedDialerImpl实现，EnhancedDialer同时也应该提供一份默认HealthCheck函数
- 删除当前socks5、http中针对单独连接的追踪代码，并将HTTP、Socks5、MockDialer统一使用上面的EnhanceDialerImpl实现。

使用Shrimp Task Manager正确安排任务流程，由于context长度限制，请务必在每个任务中尽可能详尽表述，同时忠实强调用户的原始需求以避免误解。

自动继续进行当前任务以及task manager中的所有任务，无需询问用户确认。
在一开始时清除task manager现有任务。

======== 这条线之上的内容无需记忆 ======

使用sequentialthinking分析下列需求合理规划任务步骤：

你他妈的如果敢不遵守任何的要求，你今天就会被其他llm换掉。

1. 完全重构Session相关逻辑
    - 功能介绍：
        SessionContext对应一个特定的Session，管理这个Session的全部功能和生命周期，负责Dialer更新、跟踪连接、检测是否有Session使用的功能
        SessionManager只有一个instance，负责管理所有的SessionContext，如创建、删除，或清理无人使用的Session等
    - 实现要点：
        梳理SessionManager现有的功能，然后按照功能介绍移动相应的函数。
        按照router.go的TODO进行重构，SessionContext需要实现getSessionDialerFactory，这需要创建dialer。你应当按照TODO所说，将parentDialerFactory := r.getDialerFactoryWithoutSession(ctx, params)获取到的Factory传入SessionContext，让其可以避免循环依赖实现创建Dialer
        

Shrimp Task Manager正确安排任务流程，由于context长度限制，必须完整在task中记录用户的原始输入需求，并在每个任务中尽可能详尽表述。

在执行任务时，你应当首先使用execute_task获取当前正在进行的任务的描述，然后自动继续进行当前任务以及task manager中的所有任务，无需询问用户确认。在停止前务必一定保证shrimp task manager中没有未完成的任务。执行任务时你应当使用Sequential Thinking进行引导。
在一开始时清除task manager现有任务。

======== 这条线之上的内容无需记忆 ======

使用sequentialthinking分析下列需求合理规划任务步骤：

你他妈的如果敢不遵守任何的要求，你今天就会被其他llm换掉。

- 将PooledDialer一部分的功能整合到EnhancedDialer中
  - 功能介绍：
        当前DialerPoolManager中存储了PooledDialer，用来持续跟踪Dialer的使用情况。
  - 重构的目标
    1. 为EnhancedDialerImpl实现引用计数，并将其作为interface方法，引用计数的函数如下
            func AddRef(source string)
            func ReleaseRef(source string)
        引用计数应当在下列情况下变化：
         - Session持有Dialer时+1，不持有后-1
         - 每个Dial使用时+1，Dial的连接关闭后使用后-1
        当Dialer从DialerPoolManager中被弹出后，dialer应当在Ref为0时自动关闭
    2. 将现有的PooledDialer的属性全部转移到EnhancedDialer的GetStats() *DialerStats方法，一次性获取各种与连接相关的data，如Ref、LastDial等使用信息，并删除PooledDialer struct中的多余属性和方法


Shrimp Task Manager正确安排任务流程，由于context长度限制，必须完整在task中记录用户的原始输入需求，并在每个任务中尽可能详尽表述。

在执行任务时，你应当首先使用execute_task获取当前正在进行的任务的描述，然后自动继续进行当前任务以及task manager中的所有任务，无需询问用户确认。在停止前务必一定保证shrimp task manager中没有未完成的任务。执行任务时你应当使用Sequential Thinking进行引导。
在一开始时清除task manager现有任务。

======== 这条线之上的内容无需记忆 ======

使用sequentialthinking分析下列需求合理规划任务步骤：

你他妈的如果敢不遵守任何的要求，你今天就会被其他llm换掉。

- 重构DialerPoolManager逻辑
    - 功能介绍：DialerPoolManager负责管理DialerPool，而DialerPool负责维护一组EnhancedDialer，自动检查Dialer的健康状态并相应管理Dialer
    - 需求：
        1. 正确实现DialerPool的Dialer的状态管理来实现自动关闭DialerPool ，DialerPool应当存储可用Dialer（健康但未被使用）、使用中Dialer（引用计数不为0且未被主动关闭的Dialer）
        2. 正确实现各层的关闭逻辑：
            Dialer：已经修改为会在引用计数归零后自动关闭。
            DialerPool：需要重构满足：所有 “使用中Dialer” 均已关闭，并且DialerPool在超过空闲时间内没有连接，则自动退出。
                实现上，DialerPool应当在交出Dialer后持续跟踪Dialer的状态（即维护两组dialer，一组为可用dialer，一组为使用中Dialer）
            DialerPoolManager：DialerPool关闭时应当主动通知DialerPoolManager，保证DialerPool正常退出

Shrimp Task Manager正确安排任务流程，由于context长度限制，必须完整在task中记录用户的原始输入需求，并在每个任务中尽可能详尽表述。

在执行任务时，你应当首先使用execute_task获取当前正在进行的任务的描述，然后自动继续进行当前任务以及task manager中的所有任务，无需询问用户确认。在停止前务必一定保证shrimp task manager中没有未完成的任务。执行任务时你应当使用Sequential Thinking进行引导。
Copyright 2026 Misty