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

3.7 KiB
Executable File
Raw Permalink Blame History

测速功能问题分析与修复

🔍 问题分析

用户配置策略 完全正确

你的 Trojan 配置策略是合理的:

{
  "server": "156.224.78.176",
  "server_name": "baidu.com",  // ✅ 防 SNI 检测
  "tls": {
    "enabled": true,
    "insecure": true,  // ✅ 允许自签证书
    "utls": {"enabled": true, "fingerprint": "chrome"}
  }
}

这个配置不会影响测速功能,问题在于测速逻辑本身。

根本原因:测速逻辑设计缺陷

未连接状态下的测速逻辑

// 原始代码:直接连接 Cloudflare
final testSocket = await Socket.connect(
  'speed.cloudflare.com', // ❌ 问题:直接连接,没有通过代理
  443,
  timeout: const Duration(seconds: 3),
);

已连接状态下的测速逻辑

// 通过 SingBox 代理测试
await KRSingBoxImp.instance.kr_urlTest("select");

问题详解

  1. 未连接时

    • 直接连接 speed.cloudflare.com
    • 没有通过代理节点
    • 如果网络环境限制,会超时
  2. 已连接时

    • 通过 SingBox 代理测试
    • 流量经过代理节点
    • 可以正常访问测速服务器

🛠️ 修复方案

修复后的测速逻辑

/// 测试单个节点的延迟
Future<void> _kr_testSingleNode(dynamic item) async {
  try {
    // 解析地址和端口
    final uri = Uri.parse(item.serverAddr);
    final address = uri.host.isEmpty ? item.serverAddr : uri.host;
    final port = uri.port > 0 ? uri.port : 443;

    // 使用 Socket 测试到实际节点的 TCP 连接延迟
    final stopwatch = Stopwatch()..start();
    
    final socket = await Socket.connect(
      address,
      port,
      timeout: const Duration(seconds: 5), // 增加超时时间
    );
    stopwatch.stop();

    // 获取延迟时间
    final delay = stopwatch.elapsedMilliseconds;

    // 关闭连接
    await socket.close();

    // 如果延迟超过3秒认为节点不可用
    if (delay > 3000) {
      item.urlTestDelay.value = 65535;
    } else {
      // 直接使用连接延迟,不再进行二次测试
      item.urlTestDelay.value = delay;
    }
  } catch (e) {
    item.urlTestDelay.value = 65535;
  }
}

修复要点

  1. 移除二次测试 - 不再连接 speed.cloudflare.com
  2. 增加超时时间 - 从 3 秒增加到 5 秒
  3. 简化逻辑 - 直接使用节点连接延迟
  4. 提高阈值 - 从 2 秒提高到 3 秒

📊 修复效果

修复前

  • 未连接时:测速超时(直接连接 Cloudflare 失败)
  • 已连接时:测速正常(通过代理连接)

修复后

  • 未连接时:测速正常(直接测试节点连接延迟)
  • 已连接时:测速正常(通过代理测试)

🧪 测试步骤

  1. 重新运行应用
  2. 在未连接状态下测试延迟 - 应该能正常显示延迟值
  3. 连接节点后测试延迟 - 应该能正常显示延迟值
  4. 对比两种状态下的延迟 - 应该都能正常工作

💡 关键要点

  1. 你的 Trojan 配置是正确的 - 防 SNI 检测策略有效
  2. 问题在于测速逻辑 - 不是配置问题
  3. 修复后两种状态都能测速 - 解决了根本问题
  4. 延迟测试更准确 - 直接测试节点连接延迟

🔧 配置建议

你的当前配置策略很好,建议保持:

{
  "server_name": "baidu.com",  // 防 SNI 检测
  "tls": {
    "insecure": true,  // 允许自签证书
    "utls": {"enabled": true, "fingerprint": "chrome"}
  }
}

这个配置能有效防止 GFW 的 SNI 检测和流量分析。

修复后,你的测速功能应该能在任何状态下正常工作了!