之前BUG再多也都是UI的BUG，大不了用UI连接成功之后，用任务管理器（在详情页面）结束掉"gephgui-wry.exe"之后，继续使用。
但这次BUG直接影响到了"geph4-client.exe"，躲都没处躲了。
运行一段时间后"geph4-client.exe"会故障，开始我遭遇了几次闪退，每次需要重新打开UI重连一下。
之后则变成疯狂写入日志文件，写入速度最高达到5MB/s！相当于每天约500GB写入，也相当于每年造成180TBW的总写入量！
而一些高性价比的固态硬盘可能只有150TBW或300TBW的总寿命。我说的可是三星等一线品牌哦。
出现疯狂写入日志的BUG时，代理也是无法使用的。因此无论如何都得关掉"geph4-client.exe"，再重新连接才行。
出BUG的时候，CPU占用率也变高，论坛里其他帖子反映的“一晚上手机耗光电”问题应该也是因为同样的BUG导致的。只是那个用户用的是手机，查看不了应用总写入量。
现在来看，只能是不用网时记得结束掉迷雾通进程，以免之后触发BUG浪费硬盘。
（顺带一提，日志文件又变大了。目前大小锁定在5.01GB。仍然不会无限变大。）
4 个赞
日志不断累积变大，一定时间（如数秒）内将 geph4-logs.db + geph4-logs.db-journal 二文件连接合并成一个文件 geph4-logs.db（大文件的连接合并，导致“疯狂写盘”？）
有必要保留日志文件？不是每次结束运行时手动删除它，尤其是长期不删而变得太大的时候？
1 个赞
请看看Win10 文件夹C:\Users\用户名\AppData\Roaming\Microsoft\InputMethod\Chs 下有多少个0大小的 tmp 文件
1 个赞
之后又不出BUG了。又好了。
请原谅我急着发帖反馈，这几天BUG不断。
我这边，先是迷雾通UI怎么也打不开，打开就立刻闪退，只能改用命令行运行，但是太久没出过类似问题，指令的格式改了，之前的指令用不了，导致又折腾好一阵子才登上。
之后迷雾通UI是正常了，"geph4-client.exe"又开始闪退，一天之内闪退20次（主帖中说“几次”是我记错了，实际上是20次）。于是我又得一直开着UI，闪退了就重连。
然后又出现不闪退但是卡住狂写硬盘的问题，出现两次。
这才忍无可忍发帖反馈。
然后现在突然又好了，就这么好了。我也没重启电脑，系统相关组件（Webview等）也没在此期间更新。现在既不闪退也不狂写硬盘。
（上面问到的“大小为0字节的tmp文件”我这边没有上万个，只有几千个。不知道问这个起什么作用。看了看文件的日期分布，也没有什么反常的。就是每个月有个别几天会有10多个文件，剩下天里没有文件或者零星几个。）
不定期手动删除0大小的tmp、迷雾通日志、系统临时文件。。。
但是现在速度太慢了，很多时候都在100KB的下载速度，能达到1MB的情况都很少。
1 个赞
突破二号
8
我的是win11系统的4.9.1版本迷雾通，请问下为啥点链接没有反应啊。。
1 个赞
我今天也遇到了，还好发现的早。莫名其妙系统硬盘持续写入，温度急速升高，查看进程 迷雾通占用cpu占用率飙升到10%+（amd 7950x)+,从来没见过这种情况。关闭后再打开，目前还没有异常。但我是不敢一直挂着了。睡觉一定要关了。这bug也太恶性了，直接烧硬盘。
还有系统硬盘一下子少掉了7G，我找不到写入的文件在哪里，这恶性bug也太闹心了
AnyWAT
10
不是系统还原点占用了？
没发现过系统硬盘一下子多出了7G？
瞧瞧 迷雾通4.9.1版BUG很严重，客户端疯狂写入硬盘，速度足以每年消耗一块固态硬盘的总寿命 - #2，来自 匿名1147
日志：C:\Users\用户名\AppData\Local\geph4-logs.db & geph4-logs.db-journal
其它：C:\Users\用户名\AppData\Roaming\EBWebView & geph4-credentials
今天这个bug又发生了，看来真的是不能闲时还挂着了，必须关掉
1 个赞
感谢，看到你的贴子，我今天也关注了一下，我电脑上也有这个问题。已经回退到4.8.9版本了。
今天又出这问题了。还是每秒写入4~5MB。等我发现的时候已经写了300GB（约17小时）。
某种程度上算是更严重了，因为开始狂写硬盘的时候，迷雾通代理还正常，还能通过代理翻墙，导致问题没有立刻发现。（之前出现狂写硬盘时，迷雾通是彻底连不上的。这次却仍然能断断续续地连上，和不出狂写硬盘BUG时表现没区别。）
原以为问题已经解决（我真是这么想的。虽然客户端没有更新，但考虑到迷雾通的工作原理，不排除在客户端不更新的情况下，只更新服务端，也间接影响到客户端的行为），看来还是不能放松警惕，不用时就得把迷雾通关掉。
这情况，哪怕有个选项能够把日志存放地点移到别处也好啊！把写入放到另一块机械硬盘上，至少可以不这么恶心。
这个BUG发生时间点也是尴尬，4.9.1刚好是目前为止唯一一个，迷雾通公示完安全审计结果之后，才发布的版本。
等于是只有这个版本修复了审计中的中风险问题？并且这些问题已经公开了？
如果真是这样，要回退旧版本的话，也是不太放心。
我又打开日志文件看了一下。天哪，这日志还用得着迷雾通来记？我都会记了。就一句话：
[geph4client::connect::tunnel::getsess WARN]: error replacing dead bridges: multiplex is dead
把这句每行重复若干遍，重复无数行，每秒都写好多行。就相当于迷雾通的日志内容了。
好歹合并下重复的日志内容行不？如果这件事一秒钟之内发生了1000次，你就写一遍，旁边加个括号写上(1000)不就得了？？
更正：可能我没搞清楚状况。
我又打开日志文件看了一下，出故障时，每秒多出来的日志文件大概占3KB。远远没有3MB。
但是在任务管理器里看到的硬盘占用量确实有MB级别啊，而且geph4-client.exe的总写入量达到了GB级别。
在“任务管理器”->“详细信息”页面，右击任何列的标题->“选择列”，然后加入“I/O写入字节”这一项，就能观察到我说的情况了。注意别加成“I/O写入”，那个是写入的“次数”，和总数据量没啥关系。）
然后无限重复的那一行错误，5.01GB的文件里大概记录了400万条，大概平均每天有20万条。这样算来每天生成的日志文件也就几百MB左右。
每秒好几MB的写入量可能另有原因。
不过也别怪我统计不清楚。我现在就只会用Notepad++打开这个巨大的文件，做一个搜索操作都要卡几分钟，日志文件又不是按日期排列的，导致我连“最近几天日志是否明显变多”这个问题都给不出个答案来。
比如原文后面我发先后缀每隔一段时间（说一下，是约40秒）换到新后缀，每40秒8000个后缀相同的新条目，这不是每秒200个条目吗？怎么说成是20个。我还是再观察一下吧。
更正前原文：
4.9.2版本，狂写硬盘的BUG仍然存在，出问题时我看到大约2.5~3MB每秒的写入量。
仍然是在日志里狂写那一行字
[geph4client::connect::tunnel::getsess WARN]: error replacing dead bridges: multiplex is dead
外加一些乱七八糟的字符，大概每秒记20~30遍不等。
一串大约100字节的日志内容，每秒重复20到30遍（可能低估了，见“更正”），造成了每秒约2.5到3MB的写入量。（不仅算错了，也可能低估了条目的数量，见“更正”）
希望可以尽快优化一下，就针对这一句就行。
出BUG时狂写这一行，导致5.01GB的日志文件里，超过99%都是这一行字。这日志记得有何意义。
我也注意到所谓“无限重复”的那一行，内容不完全相同。
最后往往会加一个后缀，比如
zそ?
zじ?
等等
这个后缀在一段时间内是不变的，每隔一段时间换到一个新的后缀。
如果把后缀完全一样的都合并显示，日志大概能少8000倍。
（另：我没参与任何测试活动。我这边geph4-logs.db文件大小锁定在5,381,967,872 字节，约合5.01GB。这篇回帖里的分析也正是打开这个大文件分析得到的。）
稍微统计了一下，更新到4.9.2版本之后的写入（不出BUG时）。
在此附上所谓的“正常情况”供参考吧。
前12小时情况如下：
“连接时”写入量小到可以忽略（之前4.9.1版本遇到过连接就先写入1GB）。
日志文件增加速度：0.2MB/h （合4.8MB每天）， "I/O写入字节"增加速度：60M字节/h （合720M字节每天，0.9TB每年）
时间 日志大小 "I/O写入字节" 日志增加速度 "I/O写入字节"增加速度 日志条目数量 "multiplex is dead"错误出现次数
12hr 2.4MB 480M字节 0.2MB/h 60M字节/h 32000 0
21hr 3.93MB 850M字节 0.19MB/h 41M字节/h 51000 0
注：
- 第二行21小时的数据，是把前12小时的数据也包含进去的。比如“日志增加速度”是这21小时之内的平均速度，而不只是后面9小时的。
- 1MB=1048576字节，1M字节=1000000字节。
- 之前我反复抱怨的"multiplex is dead"错误在此统计区间没有出现，估计是表明还没有遇到狂写硬盘的BUG。
- 此表格应该再增加一列：硬盘报告的总写入量增加量。但是这次没遇到BUG，迷雾通的写入量和其他应用的混在一起了。得等到出BUG时再看，应该能从这一个数据直接看出问题。
这次记录是我先把日志文件整个删除了，才开始记的。
要问我之前为什么不删……之前5.01GB的日志记录了大约20天的内容，约合“每天增加250MB”，因此当时我以为删文件也没什么意义。但是目前来看日志“每天增加不到5MB”。
而且不应该是设法裁剪旧日志，保留最新几天的吗？但是显然我不知道怎么做到这一点。
因为之前确实刚用上4.9.2版本时，一天不到就又出现BUG。所以我还不能绝对放心。
但是这个BUG毕竟还算偶发，有可能连续两周也不出现（参考我之前帖子日期），只能等到再遇到时再说了。
又遇到BUG了。4.9.2版本。
查看日志文件可以看出，这次当我发现出BUG时，BUG已经持续了2小时。
2小时之内日志文件增加了170MB。
2小时之内“IO写入字节”为23G字节。（也就是消耗掉固态硬盘约21.4GB的写入寿命，合94TB每年）
2小时之内产生了近140万条日志内容，其中131万条是那个"multiplex is dead"错误。（约合每秒180条）
相比之前正常情况：
开一整天，日志才4MB
开一整天，写入为约900MB
开一整天，日志约6万条。没有"multiplex is dead"错误。
莫非参与了该测试？