Question 1

如何防止 Yandex Telemost 通过参与者名称检测并屏蔽 OpenFlux？

Accepted Answer

OpenFlux 之前会以固定的参与者名称 "OpenFlux" 加入 Yandex Telemost 会议，这使得隧道很容易通过用户名被检测并封锁。该问题已在 core v0.5.1 和 app v2.4.1 中修复：Telemost 通道现在以 "Гость"（Guest，访客）身份加入，并使用随机化的、仿浏览器的 RTCP CNAME，因此参与者列表不再会暴露隧道。请升级到 core v0.5.1+ 和 app v2.4.1+ 以获取此修复。在旧版本上，作为临时变通方案，请从节点的传输列表中移除 Telemost。

Question 2

如何修复 mailru transport 出现的 "WebSocket dial failed (http 409): websocket: bad handshake" 错误？

Accepted Answer

Mail.ru 的 nginx 会拒绝未提供 `Sec-WebSocket-Extensions: permessage-deflate` 请求头的 WebSocket 升级请求,并返回 `HTTP 409 Conflict`。该问题影响 OpenFlux core v0.4.2 (node-v1.2.2),其中 `transport/mailru/mailru.go` 中的 gorilla/websocket dialer 在构建时未启用压缩。修复方法:在 `connectToDoc` 中,将 `websocket.Dialer` 的 `EnableCompression` 设置为 `true`:

```go
dialer := websocket.Dialer{
    EnableCompression: true, // nginx answers 409 without permessage-deflate offer
    HandshakeTimeout:  15 * time.Second,
    NetDialContext:    netbind.Wrap(&net.Dialer{...}).DialContext,
}
```

gorilla/websocket 仅在 `EnableCompression` 为 true 时才会发送 `Sec-WebSocket-Extensions` 请求头。完成这一行修改并重新构建后,握手返回 `101 Switching Protocols`,载体(carrier)成功连接(`[M-DOCS] WebSocket connected`),流量恢复正常。压缩在 WebSocket 层面协商,并由库透明处理,因此隧道协议不受影响。User-Agent、Origin 和 cookies 均无关紧要——只有压缩请求头才是关键。

Question 3

如何修复 OpenFlux 中 Mail.ru Docs 传输失败，出现 'API returned status 500' 和 WebSocket close 1005 错误的问题？

Accepted Answer

Mail.ru 在 10 月 12 日 16:00 UTC 左右更改了其 API（r7/edit 端点 / WebSocket 行为），导致与 node-v1.3.1 的兼容性失效。症状：`[M-DOCS] cannot open the document: API returned status 500` 和 `websocket: close 1005` 重连循环，每约 60 秒出现一次，客户端卡在 direct transport 上。修复方法：将出口节点更新到最新版本——开发者已修复 Mail.ru API 兼容性，用户确认更新后即可正常工作。启用自动更新后，节点会自行升级；否则请手动拉取并重启最新的节点版本。无需更改配置或文档——重新创建文档/频道并无帮助，因为该问题是服务端 API 变更，而不是你的文档问题或 IP 被封。

Question 4

如何修复非 .ru 域名（如 docs.yandex.kz）上的 Yandex transport 验证码错误（HTTP 400 或 "config not found: no client-config script"）？

Accepted Answer

这是验证码处理代码中的一个 bug（在提交 38782b2 中引入），现已被维护者修复——请更新到比 main@d13aa5b 更新的构建版本。有两个根本原因：(1) `transport/yandex/captcha.go` 在 `Origin` 请求头和表单 action 中硬编码了 `https://docs.yandex.ru`，导致第一级 `showcaptchafast` PoW 求解在区域性域名（例如 `docs.yandex.kz`）上返回 HTTP 400。修复方式是动态获取主机名：解析 `url.Parse(captchaURL).Host`，并将其同时用于 `Origin` 请求头和 `formAction` 前缀（单文件约 10 行的补丁），之后 POST 请求返回 302（已解决）。(2) 第二级挑战 `showcaptcha?cc=1&...`（一个约 14KB 的页面，不含 `window.__SSR_DATA__`/`tmgrdfrend-form` 标记）未被处理，导致 `fetchDocInfo` 失败并报错 `config not found: no client-config script`。注意：这与 IP 信誉/速率限制无关——在全新 IP 的第一个请求上即可复现。更新到最新版本可以修复这两个问题；在受影响的构建版本上没有配置项可以绕过。

Question 5

为什么在使用 Yandex 传输时，OpenFlux VPN 会话握手会超时？

Accepted Answer

根本原因:原生 Yandex 传输(`transport/yandex/yandex.go`)和内置的 Yandex JS 传输将每个数据包的 cursor 负载长度前缀硬编码为 `18`,而不考虑实际的二进制大小。Yandex 的服务器不会转发声明长度与实际负载不匹配的 cursor 消息,因此握手数据包永远无法到达对端,即使 WebSocket 保持连接,会话也会失败并报错 `handshake FAILED after 20s: handshake timed out`。

修复:修改 `transport/yandex/yandex.go`(以及 JS 传输),使 cursor 前缀等于 Base64 编码之前的实际二进制数据包长度(例如,16 字节的数据包使用 `16;<base64>`),而不是常量 18。受控测试证实,前缀不匹配时送达率为 0/3,而前缀正确时两个方向的送达率均为 3/3,包括 64/512/1500 字节的数据包。

变通方案:保持启用 Direct 传输回退(例如 `--transports=yandex:100,direct:50`),这样当 Yandex 中继丢弃数据包时,会话可以通过 Direct 完成。请注意,可用的 Direct 路径可能会掩盖 Yandex 的故障,因此在测试修复时应禁用 Direct 进行验证。

OpenFlux

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐