LighthouseApp/CONNECTION_REFUSED_ISSUE_ANALYSIS.md
speakeloudest 75d4c48e41
Some checks failed
Build Windows / build (push) Has been cancelled
feat: 源码提交
2025-10-19 23:30:54 -07:00

4.3 KiB
Executable File
Raw Blame History

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 等)
  • 不再使用随机的大数字端口

📝 总结

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

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

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

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