Geph 5.9.1 校园网连接异常 上午正常 下午持续卡在连接中
我是让Codex分析的，因为我是小白
今天（2026 年 10 月 9 日）上午，Geph 在校园网下还可以正常连接；下午开始一直卡在“连接中”，无法建立连接。具体开始时间没有准确记录。
使用环境
电脑使用 Arch Linux，内核为 Linux 7.2.9，Geph 版本为 5.9.1。
不过手机上也有相同现象，我认为和系统没关系，手机也是5.9.1
Geph 只启用了本地代理 ，没有启用全局代理的 TUN 模式，也没有启用“自动配置代理服务器”。后续代理方案使用 dae，但目前 Geph 自身就无法完成连接。
已观察到的情况
- 电脑接入校园网后，Geph 持续停留在“连接中”。
- 同一台电脑改用手机热点后，可以正常连接。
- 手机上的 Geph App 接入校园网，也出现相同问题。
- 电脑通过命令行方式连接，同样失败。
- 连接设置仅指定国家时，也无法连接。
- DNS 分别试过 1.1.1.1、AliDNS，以及 DHCP 下发的 DNS ，均未能解决连接问题。
抓包记录
抓包在电脑上进行，文件为 geph5-debug.pcap ，时间为 2026 年 10 月 9 日 18:33:07 至 18:34:06，北京时间 ，持续约 59 秒，共 8,946 个数据包。
以下是抓包中观察到的报文情况，帧号均对应原始文件。
TLS 握手期间收到复位包
连接地址为：
10.252.99.229:60236 → 89.187.187.12:443
ClientHello 中的 SNI 为 www.cdn77.com 。
- 帧 179、191、192：完成 TCP 三次握手。
- 帧 193：发送 TLS ClientHello。
- 帧 194：约 4.582 毫秒 后收到
RST ACK ，源地址为 89.187.187.12 ，TTL 为 249 。
- 帧 199、201：随后又收到同一连接的 ACK 和 TLS ServerHello，TTL 均为 48 。
- 帧 200、203、204：电脑向后续到达的报文发送 RST。
多条连接反复建连或重传首包
抓包中反复尝试连接以下端点：
175.29.23.238:6882
150.241.210.125:45870
52.192.243.89:10404
52.199.66.218:30384
14.137.237.79:42400
14.137.237.61:65279
按独立 TCP 流统计，共有 36 次连接尝试 ：20 次在抓包窗口内未见对端回复；另外 16 次完成 TCP 三次握手，但之后未见对端确认首批数据或返回应用数据。
其中：
-
TCP 流 13 ，目标为
150.241.210.125:45870 ：握手约 93 毫秒完成，随后发送 1136 字节首包，同一段数据重传 8 次。首发到最后一次观察到的重传间隔约 38.426 秒 ，期间未见数据确认。
-
TCP 流 17 ，目标为
14.137.237.61:65279 ：握手约 97 毫秒完成，随后发送 206 字节首包，同样重传 8 次，首发到最后一次观察到的重传间隔约 38.933 秒 ，期间未见数据确认。
-
52.199.66.218:30384 和 14.137.237.79:42400 各出现六次连接尝试，均未见对端回复，报文表现为反复发送 SYN。
以上统计仅覆盖本次约一分钟的抓包窗口。
同期也有正常通信
抓包中，一条对 config.immersivetranslate.com 的 HTTPS 连接完成了 TCP 和 TLS 握手，随后有双向数据交换并正常关闭。
Firefox 的联网探测分别收到 HTTP 204 和 HTTP 200，后者正文为 success 。
目前只有电脑在校园网下的这份抓包，没有手机端或热点下的对照抓包。想请问是否有其他用户今天下午遇到相同情况，以及还需要补充哪些日志。
测试了一下Geph 5.9.0没有变化
测之前我有禁用geph-manager.service并让重新安装的版本再次注册服务
我提到了哦，命令行注册的geph-manager也是一样呢
注册，正常安装即正常，主要是设置，不正常下的流程，测试。。。
❯ geph5 exit-constraint set --country "us"
Exit constraint set to US.
❯ geph5 connect
Connecting…
❯ geph5 status
State: connecting
Traffic: 0.00 MiB down / 0.00 MiB up
Mode: proxy | lan-access off | allow-direct off | auto-proxy off
❯ geph5 status
State: connecting
Traffic: 0.00 MiB down / 0.00 MiB up
Mode: proxy | lan-access off | allow-direct off | auto-proxy off
❯ geph5 status
State: connecting
Traffic: 0.00 MiB down / 0.00 MiB up
Mode: proxy | lan-access off | allow-direct off | auto-proxy off
❯ geph5 status
State: connecting
Traffic: 0.00 MiB down / 0.00 MiB up
Mode: proxy | lan-access off | allow-direct off | auto-proxy off
❯ geph5 status
State: connecting
Traffic: 0.00 MiB down / 0.00 MiB up
Mode: proxy | lan-access off | allow-direct off | auto-proxy off
也是卡在这里呢
1 个赞
写了Connecting, 实际当作代理服务器也是无法使用的
1 个赞
连接不上，清理迷雾通缓存，或
geph5 reconnect
或：
不知道cache.db和config.yaml在哪里
算了今天先不折腾了
相同问题，macos系统，在application support/geph下未找到config.yaml或cache.db文件
1 个赞
Win系统迷雾通图形模式下自动生成 child-config.yaml
文件夹C:\ProgramData\geph\cache 下按字母升序排列，删除第一、三俩文件，一般是最大的俩文件。
我让谷歌AI分析我的日志文件他是这么回答的：
从你提供的日志来看，你的迷雾通（Geph 5）目前卡在“向核心服务器（Broker）请求网络状态和认证”的阶段。日志中只有大量的 calling broker through http（通过 HTTP 域前置技术调用 Broker）的 DEBUG 记录，并没有进入实质性的节点连接阶段（SOSISTAB3 握手或相关代理连接日志）。
以下是具体的日志分析原因及排查解决办法：
日志原因分析
-
死循环在 Broker 请求：
日志中不停地重复调用 get_net_status（获取网络状态）、get_account_secret_status（获取账户安全状态）和 get_user_info_by_cred（验证凭据）。这意味着客户端正在尝试通过 Bunny.net、CDN77、Gcore 等 CDN 域前置通道去联系迷雾通的中央服务器。
-
缺乏“成功”或“失败”的下一步反馈：
正常的日志在调用 Broker 成功后，会开始下载节点列表并输出 connecting to...。如果彻底失败，通常会抛出超时（Timeout）或拒绝连接（Connection Refused）的 ERROR。而你的日志一直卡在 DEBUG 循环，说明请求发出去了，但可能由于当地网络干扰（如大丰收、节点更新后的 GFW 策略封锁），回包被严重丢弃或延迟，导致客户端一直在反复重试。
也就是今天中午跟新的节点被一些运营商针对性封锁了。
貌似是（配置文件前半部的 broker）网桥，如截图 Geph 5.9.1 校园网连接异常 上午正常 下午持续卡在连接中 - #9，来自 AnyWAT_后置快稳安
可以借助其它VPN临时帮扶一下（作为前置代理）？
运行可修改配置文件的（批处理）命令行+后置代理。。。
本截图，默认（桥）配置文件的命令行+后置代理 个人反馈帖 - #122，来自 AnyWAT_后置快稳安
