hi-client/CONNECTION_REFUSED_ISSUE_ANALYSIS.md

Connection Refused 问题分析和修复

🔍 问题现象

从日志中可以看到所有节点都出现 "Connection refused" 错误：

❌ 本机网络测试节点 德国 失败: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 156.226.175.116, port = 51036
❌ 本机网络测试节点 美国 失败: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 154.29.154.241, port = 59118
❌ 本机网络测试节点 英国 失败: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 89.213.40.159, port = 45268
❌ 本机网络测试节点 台湾 失败: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 83.147.12.27, port = 49826
❌ 本机网络测试节点 香港 失败: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 156.224.78.176, port = 44782

🎯 问题分析

1. 地址解析问题

问题现象:

• 所有节点的端口都是随机的大数字（如 51036, 59118, 45268 等）
• 这些端口看起来不像是正常的代理服务端口

根本原因:

• 原来的代码使用 Uri.parse(item.serverAddr) 来解析地址和端口
• 但是 serverAddr 可能不包含端口信息，或者解析逻辑有问题
• 端口应该从节点的配置中获取，而不是从 serverAddr 中解析

2. 配置获取问题

问题现象:

• 没有从节点的配置中获取正确的端口号
• 使用了错误的默认端口或解析出的错误端口

根本原因:

• 节点的端口信息存储在 item.config['server_port'] 中
• 原来的代码没有正确获取这个配置

🔧 修复方案

修复内容:

1. 改进地址解析逻辑:

   // 从配置中获取正确的地址和端口
   String address = item.serverAddr;
   int port = 443; // 默认端口
   
   // 如果serverAddr包含端口，先解析
   if (item.serverAddr.contains(':')) {
     final parts = item.serverAddr.split(':');
     if (parts.length == 2) {
       address = parts[0];
       port = int.tryParse(parts[1]) ?? 443;
     }
   }
   
   // 从配置中获取端口（优先级更高）
   if (item.config != null && item.config['server_port'] != null) {
     port = item.config['server_port'];
     KRLogUtil.kr_i('📌 从配置获取端口: $port', tag: 'NodeTest');
   }
   

2. 增加详细日志:

   KRLogUtil.kr_i('📋 节点配置: ${item.config}', tag: 'NodeTest');
   KRLogUtil.kr_i('📍 最终地址: $address, 端口: $port', tag: 'NodeTest');
   

修复逻辑:

1. 地址处理:

   • 首先使用 item.serverAddr 作为地址
   • 如果包含端口，则分离地址和端口
   • 否则使用默认端口 443

2. 端口获取:

   • 优先从 item.config['server_port'] 获取端口
   • 如果配置中没有端口，使用解析出的端口或默认端口

3. 日志记录:

   • 记录节点配置信息
   • 记录最终使用的地址和端口
   • 便于调试和问题排查

📊 预期效果

修复前:

• 使用错误的端口（如 51036, 59118 等）
• 所有节点连接被拒绝
• 无法获取真实的延迟信息

修复后:

• 使用正确的端口（从配置中获取）
• 能够成功连接到节点
• 获取真实的网络延迟

🔍 验证方法

1. 检查日志:

• 查看 📋 节点配置: 日志，确认配置信息
• 查看 📌 从配置获取端口: 日志，确认端口获取
• 查看 📍 最终地址: 日志，确认最终使用的地址和端口

2. 测试连接:

• 确认不再出现 "Connection refused" 错误
• 能够获取到合理的延迟值（通常 < 5000ms）
• 部分节点可能仍然超时，但应该有一些节点能够连接成功

3. 端口验证:

• 确认使用的端口是合理的（如 443, 80, 8080 等）
• 不再使用随机的大数字端口

📝 总结

问题根源: 地址和端口解析逻辑错误，没有从节点配置中获取正确的端口信息。

修复方案: 改进地址解析逻辑，优先从节点配置中获取端口，并增加详细的日志记录。

预期结果: 能够使用正确的地址和端口连接节点，获取真实的网络延迟信息。

现在可以重新测试，应该能够看到正确的端口和成功的连接！