单凭肉眼观察发现以下几个内存泄漏点，可能不完整：

第一个：
cJSON *cjson_receive = cJSON_Parse((char *)buffer);
一旦 if (strcmp((char *)buffer, "shutdown") == 0)这里 break 掉，后面的 cJSON_Delete(cjson_receive)就无法执行，内存就这样泄露掉了

第二个：
videoSource::Create()调用了两次，第一次问题不大，第二次处理不妥
原因同第一次。如果 input 创建成功但 output 创建失败，那么随后的 continue 会导致 input 指针内存泄漏。

第三个：
if (!socket->Send((void *)json_str, strlen(json_str), remoteIP, remotePort))
同理，break 之前未释放内存

建议上述内存分配都用智能指针包起来，必要时传递析构用的释放函数，就像这样：
std::unique_ptr<cJSON, decltype(cJSON_Delete)> cjson_receive{ cJSON_Parse((char *)buffer), cJSON_Delete };

看起来用的是 tap 接口，所以路由通告双向透传了

换成 tun 接口试试，应该是最省心的做法

或者也可以在两侧都设置屏蔽对方的 FF00::/8

做 C++（以及 C 开发）需要严格区分以下种类：
32 位与 64 位
debug 与 release
动态库与静态库

从你给出的编译命令来看，是编译出 x64 debug 版本，至于是动态库还是静态库我就不去挖掘了。
然后在 qt creator 内用的是哪一种组合？这也是要注意的，如果能够贴出具体的报错提示和设置，那么大家可以更容易帮你给出编译设置步骤

初看标题，以为是 cyber security 的 phishing

点进来一看，没想到原来是真正的 fishing

换成 qbittorrent enhanced edition ，主动拒绝吸血鬼

OPNSense 透明代理（正向代理）的实现方式，本质就是“HTTPS 中间人攻击”用于无害用途。
某些 App 为了防止中间人攻击，可能会把锁定信任证书。

这里有篇文章可以参考下：
https://stack.chaitin.com/techblog/detail/40

建议观察下 Log 的内容，是不是也像他这样：
https://www.reddit.com/r/OPNsenseFirewall/comments/udmfak/tons_of_errors_with_web_proxy_and_transparent_ssl/

为什么不直接运行 qemu 呢，总比多层“套娃”好吧

底部

因为我用双显示器，任务栏放在左右两侧一点都不方便

人太多上传带宽太拥挤，而 5G 流畅的话，那应该就是 4G 信道过于拥挤了，看得出这附近连 4G 基站都不够多

最稳妥的办法：连回国内家里的宽带

这里有一份十分详细的列表
https://gist.github.com/mondain/b0ec1cf5f60ae726202e
有部份服务器已经过期，需要自己再进一步筛选

既然喜欢手游，那就让他试试手游代练嘛，起码算是用爱好来赚钱

再不行就去快餐店，麦当劳、肯德基之类的，流程标准化、容易学习，应该会比奶茶店更容易适应

@lanthora 没错，就是他。越是帮他，他接下来越会继续提更多 issue

要是没帮他的情况下继续提更多 issue ，那得看着办了

我那帖子里面 Ipsum 的评论：直接摆烂
个人认为这是最佳应对措施

7950X3D 用了将近半年，毫无问题

有个网络小白一直在我的项目内纠缠“套壳建 WireGuard 隧道”，很想把他转给 OP
/t/1034681
告诉他是网络小白，12 个小时前他开骂了，还把之前的部份 comment 删掉，哈哈哈哈

准确来说，不是它们“喜欢默认路径在 C 盘”，而是微软的环境变量指向了 C 盘，即使仅仅按照微软的要求来做、用 Windows API 获取路径，最终都会写到 C 盘

常用的%APPDATA%、%LOCALAPPDATA%、%ProgramData%、%ProgramFiles%，本身都在 C 盘，所以使用环境变量获取路径得到的都是 C 盘路径

方法 2 还有一个实现方式，进入“磁盘管理器”，把个空白分区的删掉分区驱动器号（盘符），挂载到现有目录里面，就像 UNIX 那样