很长一段时间以来，我的trojan经常性地断线，需要经常重启它，才会好用一段时间。这很让我苦恼，我曾多次尝试修复它。但鉴于我自己的网络知识有限，每次只能依赖于通过Google搜索学习，又或者AI辅助来排查，弄了几次，都是能好上半天，但是又坏。最近，我终于搞定了这个问题，因此来分享一下。

trojan我已经使用了好多年了。有多久呢？我从Ubuntu 18.04 LTS开始，一路从20.04，22.04用下来。我虽然用的是LTS版本，但是我向来不用最新，而是使用更稳定的次新版。因此，到目前为止，我还没有使用24.04。

排查的方式

我把排查的思路写下来，如果你遇到了问题，也可以这么排查。当trojan的客户端连接之后，测速超时时，需要按照以下排查。

1. 查看nginx里的正常网站能否使用，如果不能，则可能是nginx服务可能有问题，又或者是连接数不足。
   1. 如果是nginx服务有问题，则重启nginx服务。这个可能性比较小。
   2. 连接数不足，可以扩大连接数。
2. 此外，也可能是DNS的问题。Linux服务器默认都会开启本地的DNS缓存，而且首选是虚拟机提供商提供的内部服务器。可是我使用的虚拟机提供商Vultr，提供的DNS内部服务器不够稳定，一旦它出了问题。也会导致trojan服务无法使用。
   1. 这类问题可以通过ping -c 3 goole.com或者查看trojan的日志来看error的类型是否是无法解析域名之类的确定。
   2. 解决办法是添加1.1.1.1，8.8.8.8这类第三方服务器到本地服务器的下方作为备用。
   3. 添加检测的脚本到cron，每5分钟执行一次，检测到了此类错误，就重启对应的dns缓存服务。

这两类问题解决之后。trojan偶尔还是会出现问题。通过查看，我发现原来trojan的代码由于太过古老，它在2021年就已经停止更新了。它在22.04下存在内存泄露。正常使用的情况下，它的内存占用只有10MB左右，但是一旦内存泄露，会逐渐膨胀到400多MB。这应该还不是它的极限，只不过是我的虚拟机只有1GB的内存，所以它最多也就能占用这么多的内存。

如果你的trojan的日志里有stream失败的错误信息，然后你看到了占用内存异常的大。就可以直接重启trojan服务。

将trojan占用内存的命令写入脚本，然后遇到大于20MB，就重启trojan服务。这可以也可以添加到cron，5分钟运行一次。

结论

原本在18.04，20.04下运行相当稳定的trojan服务，在22.04下运行的时候却因为太过古老存在内存泄露。同时虚拟机提供商提供的本地DNS服务器不够稳定，有时也会导致问题。因此，我们创建脚本，定时检测这两方面的问题，如果遇到了，就重启对应的服务。

前面我提到的信息都比较简略，这是因为在如今的时代，你只需要这些简略的信息，然后将它作为提示词，询问你自己习惯使用的AI就可以了。所以，这些简略信息已经足够了。

trojan作为一个多年停止更新的服务，目前在最新的系统中使用，已经明显过时了。解决的办法是在docker中使用旧版的Ubuntu系统。又或者想我这样，使用脚本在需要时重启服务。更好的办法是使用更现代的，更新更频繁的其他服务，比如v2ray之类的。

我是一名苹果设备的开发者，我开发过iOS、macOS、watchOS以及visionOS的应用。

大家可能注意到最近两周我提交到Copilot Xcode的bug变少了，这是因为我开始尝试使用命令行的方式编程。经过这段时间的使用，我发现二者各有优缺点。从长期来看，我认为图形界面的胜算更大，但是短期内它的缺点让我远离它。

下面我说的优缺点都是针对Copilot的亲自使用。一个是Copilot CLI，一个是GitHub Copilot for Xcode。

命令行方式的优点

更自由

命令行通常可以访问磁盘的全部空间，甚至可以帮助不熟悉使用的用户修改自己的配置文件。

使用命令行时，不必一直保持Xcode的窗口在最前。因此，可以利用这个时间多开几个窗口，或者干一些其他的事情。比如说刷刷X。图形界面就不行，它必须保证Xcode的在最前。如果不在最前，它就会不停的把它切换到最前。我之前反映过这个问题，开发者认为，会影响到其他的一些功能的实现。但是我觉得至少应该提供个选项来打开或者关闭这种吧。比如说让图形界面更接近命令行的方式。

更少的打断

使用图形的时候经常遇到打乱，一般是上下文不足。但是使用命令行的时候，从来没有遇到过类似的事情。命令行的中断往往是网络造成的，或者是配额超限造成的。

图形方式的优点

更简单的划定范围和指定区域

图形方式可以直接获得当前的文件，因此上下文更加简洁。AI往往可以在第一时间找到自己需要修改的内容。这一点是命位行方式无法比拟的。命令行要做到这一点，需要在复制粘贴之间反复切换。先复制文件名，然后再粘贴到命令行上。这个步骤虽然简单，但是很繁琐。远远没有通过鼠标点击那么简单。而且图形界面这种操作是自然而然的，不必特意去操作。

而如果在命令行下，你没有提供具体的文件信息，它就会在项目中整体的搜索，往往会花费更长的时间。甚至有时都找不到。

阻止我继续使用命令行，而不是图形的原因

长期以来，存在一个一直未解决的问题。就是图形界面下经常会写错文件。明明应该修改A的文件的内容，但是却将全部内容写入到了B文件中，并将B文件覆盖。这个问题我已经提交很久了，但是一直也没能修复。而这个问题可比上面提到的命令行的缺点要难以忍受的多。

以上就是我对这个问题的一些简单的看法。欢迎大家讨论，提出更好的意见和建议。

这两天我的Trojan非常不稳定，经常断连。比如昨天下午开始一直到晚上都不行。今天凌晨3点多好了，结果6点多又不行了。一直到刚刚，我决定看看到底是什么原因，能否自己修复。

遇事不决问AI

我先将我的困境描述给了AI。

• trojan服务通过nginx代理，nginx的443端口访问正常，正常的https能访问，之前trojan也一切正常。但是最近两天经常有部分时段trojan就不能用了。这是什么原因？

AI给出了五条可能的主要原因：

1. 运营商或防火墙干扰
2. Nginx 配置问题或代理条件变化
3. Trojan 后端服务自身问题
4. 证书自动续签/变更导致短暂异常
5. 攻击或扫描压力过大

我最担心的其实是第一条，因为对于这条我自己无能为力。AI同时提供了排查的顺序。

我选择首先排查trojan的状态。很幸运，这里面就有几个错误。我把日志发给AI。

status trojan
● trojan.service - trojan
     Loaded: loaded (/etc/systemd/system/trojan.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-09-09 10:16:44 UTC; 15h ago
       Docs: https://trojan-gfw.github.io/trojan/config
             https://trojan-gfw.github.io/trojan/
   Main PID: 859 (trojan)
      Tasks: 2 (limit: 1005)
     Memory: 144.2M
        CPU: 12.064s
     CGroup: /system.slice/trojan.service
             └─859 /usr/local/bin/trojan /usr/local/etc/trojan/config.json

Sep 10 01:52:23 vultr trojan[859]: [2025-09-10 01:52:23] [INFO] 127.0.0.1:55918 authenticated as 7ac54067666
Sep 10 01:52:23 vultr trojan[859]: [2025-09-10 01:52:23] [INFO] 127.0.0.1:55918 requested connection to www.gst>
Sep 10 01:52:24 vultr trojan[859]: [2025-09-10 01:52:24] [INFO] 127.0.0.1:55928 authenticated as 7ac54067666
Sep 10 01:52:24 vultr trojan[859]: [2025-09-10 01:52:24] [INFO] 127.0.0.1:55928 requested connection to e7.i.le>
Sep 10 01:52:32 vultr trojan[859]: [2025-09-10 01:52:32] [INFO] 127.0.0.1:36566 authenticated as 7ac54067666
Sep 10 01:52:32 vultr trojan[859]: [2025-09-10 01:52:32] [INFO] 127.0.0.1:36566 requested connection to www.goo>
Sep 10 01:52:42 vultr trojan[859]: [2025-09-10 01:52:42] [ERROR] 127.0.0.1:55762 cannot resolve remote server h>
Sep 10 01:52:42 vultr trojan[859]: [2025-09-10 01:52:42] [INFO] 127.0.0.1:55762 disconnected, 0 bytes received,>
Sep 10 01:53:02 vultr trojan[859]: [2025-09-10 01:53:02] [ERROR] 127.0.0.1:55792 cannot resolve remote server h>
Sep 10 01:53:02 vultr trojan[859]: [2025-09-10 01:53:02] [INFO] 127.0.0.1:55792 disconnected, 0 bytes received,>

AI也发现了这个错误，并分析说“也就是说，Trojan 运行没问题，但访问网站时遇到了 DNS 解析失败。这点非常关键！”

AI进一步分析：

• VPS供应商自身DNS故障（Vultr、搬瓦工等偶有发生）。
  • /etc/resolv.conf 中DNS服务器填错，或者被systemd-resolved之类自动修改导致的DNS挂掉。
  • 本地防火墙或iptables阻断了外发的53端口。
  • 系统资源紧张（低内存、负载高）可能导致系统进程异常，systemd-resolved或dnsmasq死掉。

知道了原因，解决就很简单了。重启DNS服务和Trojan，故障解决。