把 Fedora 44 配成一台可长期远程使用的开发机

最近我给另一台电脑安装了 Fedora 44 KDE Plasma，准备把它作为一台长期在线的 Linux 开发机。

我的目标不只是装好系统，而是能够从另一台电脑通过 RDP 连进去，稳定使用中文输入法、浏览器、编辑器、AI 工具、代理和备份软件。实际配置下来，最麻烦的地方并不是安装某一个软件，而是图形会话、睡眠策略、VPN 权限、代理出口和后台服务之间会互相影响。

这篇文章记录实际遇到的问题、最终采用的处理方式，以及还有哪些地方没有完成。内网地址、代理节点、访问密钥和账号信息都已删除。

先说结论

这台机器最后可以作为日常 Linux 开发机使用，但我得到的几个结论是：

• “关屏”与“休眠”必须分开处理，远程机器可以关闭显示器，但不能自动休眠。
• xrdp 创建的是独立图形会话，不等于远程观看物理显示器上的桌面。
• RDP 黑屏不一定是显卡或显示器坏了，更常见的是旧会话、重复登录或桌面进程状态冲突。
• Outline 这类 VPN 客户端如果运行在受限沙盒里，能打开界面不代表它有权限创建 TUN 设备。
• 代理软件显示“已连接”不等于所有软件已经走代理，必须检查模式、出口和目标服务。
• Syncthing 是同步，不是备份；Pika Backup 仍然需要单独的备份目标。
• Fedora 默认的 ZRAM、Btrfs 压缩、TRIM 和 AMD 开源驱动已经比较合理，不需要为了“优化”随便改内核参数。

远程连接为什么必须让显示器亮着

一开始最明显的问题是：通过远程桌面连接时，似乎只有远端显示器保持开启才能正常使用。

我先把系统改成“可以关屏，但永不自动休眠”，同时关闭 Wi-Fi 省电。这里必须区分三个状态：

1. 显示器熄灭；
2. 图形会话锁定；
3. 整台电脑进入睡眠。

显示器熄灭通常不会影响后台服务，但电脑睡眠以后，网络、SSH、RDP 和同步服务都会停止。对长期远程使用的机器来说，避免自动休眠比强制点亮显示器更重要。

后来继续检查才发现，我使用的是 xrdp。xrdp 通常会创建一个独立的 Xorg 会话，物理显示器上的 KDE 会话和 RDP 里的 KDE 会话并不是同一个桌面。所以本地显示器黑屏、RDP 黑屏和系统睡眠可能是三件不同的事。

xrdp 登录后黑屏

调整睡眠策略以后，RDP 仍然出现过黑屏。注销按钮有时也没有反应，重新连接后还是看不到桌面。

这类问题不能只盯着显示器。更有用的检查顺序是：

1. 先确认 SSH 是否仍然能连接；
2. 查看 xrdp 是否创建了新的 Xorg 显示；
3. 检查同一用户是否保留了多个 Plasma 会话；
4. 注销旧会话后重新建立 RDP 会话；
5. 确认 kwin_x11 和 plasmashell 已经在新的显示上运行。

实际处理后，RDP 使用的是单独的 X11 Plasma 会话。注销旧会话并重新连接，比反复重启显示器更有效。

目前还有一个性能限制：RDP 会话里的 OpenGL 渲染器是 llvmpipe，也就是主要依靠 CPU 软件渲染，而不是直接使用 Radeon RX 6700。普通编辑和终端没有问题，但窗口动画、模糊效果和复杂网页会增加延迟。

后续可以测试 Fedora 的 xorgxrdp-glamor，尝试让 AMD GPU 参与远程会话渲染。不过这类修改有再次黑屏的风险，必须先保留 SSH 和软件渲染回退方案，不能直接在唯一的远程通道上盲改。

Outline 能打开，但不能创建 VPN

安装 Outline 客户端以后，我遇到过三类错误：

failed to connect NetworkManager DBus
failed to create tun device: no such file or directory
failed to create tun device: ioctl: operation not permitted

它们看起来都像“连接服务器失败”，实际指向不同层面。

找不到 system bus socket，说明应用运行环境访问不到系统 D-Bus；找不到 TUN 设备，说明 /dev/net/tun 不存在或没有映射进应用环境；operation not permitted 则说明设备虽然存在，当前进程仍然没有创建网络接口所需的能力。

这里不应该为了让软件跑起来，就把设备权限改得非常宽，也不应该用 root 直接运行整个图形客户端。VPN 客户端涉及系统网络配置，沙盒、NetworkManager、TUN 和权限必须一起满足。

这次我没有继续把 Outline 强行改到可用，而是另外安装了 Mullvad 和 Clash Verge Rev。对日常代理来说，Clash 的节点和规则更容易检查；真正需要完整 VPN 隧道时，再使用具有原生系统集成的客户端。

Clash 显示已连接，为什么访问仍然没有变化

把 Shadowsocks 节点加入 Clash 以后，最初“连接”并没有带来预期效果。

最后需要同时确认这些事情：

• 节点是否真的被选中；
• 当前模式是 Rule、Global 还是 Direct；
• 系统代理或 TUN 是否启用；
• 应用本身是否忽略系统代理；
• 本地地址是否被错误送进代理；
• 代理出口是否符合目标服务的地区要求。

为了先排除规则问题，我把模式切换到 Global，再分别验证普通网页和目标服务。这样可以证明节点本身是否可用，然后再决定要不要恢复到规则模式。

对于 Electron 应用，我还使用了一个用户级启动包装器，同时设置代理环境变量和 Chromium 的 --proxy-server 参数。这样 ChatGPT 和 Antigravity 不必依赖每个桌面环境都能正确传递代理设置。

但这里还留下一个安全问题：检查时发现 Clash 的 allow-lan 仍然是 true，混合代理端口监听在所有网卡上。如果不准备让局域网里的其他设备使用这台电脑做代理，应该改成只监听 127.0.0.1。代理能用以后，还要继续检查它有没有不必要地暴露给局域网。

ChatGPT 的 403 和 404 不是同一个问题

ChatGPT 登录时出现过地区不支持的 403。这个问题与代理出口有关，切换到能够访问服务的出口并让客户端完整经过代理后，登录才能继续。

后来又遇到过内部 Codex 请求返回 404。相同的后端路径在另一条网络路径上也曾返回同类错误，这更像服务端、账号授权或路由状态异常，而不是 Fedora 安装损坏。

所以排障时要区分：

• 403 地区限制：先检查出口地区与账号可用性；
• 网络超时：检查代理、DNS 和客户端是否真正使用代理；
• 内部接口 404：不要立刻重装系统或删除账号，先保留会话、稍后重试并记录发生时间。

看到一个 HTTP 状态码就重新安装软件，通常只会增加新的变量。

中文输入法改成 Fcitx 5

系统安装完成以后还缺少稳定的中文输入。我最后改用 Fcitx 5，并让 KDE 会话使用它作为输入法框架。

输入法安装以后最好注销并重新登录，因为应用启动时就会读取输入法相关环境。如果只重启某一个软件，可能出现终端能输入中文、Electron 应用却不能输入，或者新旧输入法框架同时运行的情况。

目前 Fcitx 5 已经在 RDP 会话里正常启动。对于长期使用的 Linux 桌面，中文输入法应该在浏览器、VS Code、终端和 Electron 应用里分别测试，不能只看输入法图标是否出现。

开发环境尽量分成系统包和用户工具

这台机器安装了 Chrome、VS Code、GitHub CLI、Tailscale、ChatGPT、Antigravity，以及 Rust、Node.js 和 Java 等开发环境。

后来又补充了这些命令行工具：

• ripgrep、fd、fzf 和 btop；
• direnv、lazygit；
• pnpm、uv、pipx；
• CMake、Ninja、Clang 和 LLDB；
• ShellCheck 和 shfmt。

能从 Fedora 官方仓库安装的编译工具，我优先交给 DNF 管理。pnpm 通过现有 Node.js 的 Corepack 启用，lazygit 使用官方发布包安装到 ~/.local/bin，并校验下载文件。

direnv 的 Bash 钩子放在独立的 ~/.bashrc.d/direnv.sh 中，而不是反复改写整份 .bashrc：

eval "$(direnv hook bash)"

这样以后删除或调整配置都更清楚。

Antigravity 使用用户级安装

Antigravity 当时提供的是 Linux x64 压缩包。我没有为了安装一个桌面应用去引入额外第三方仓库，而是把官方包解压到用户目录，再创建启动命令和桌面入口。

这种方式有几个好处：

• 不需要 root 权限；
• 安装范围只属于当前用户；
• 可以明确知道程序文件放在哪里；
• 以后升级时可以保留旧版本并验证新版本。

启动以后，我不仅检查了进程，还确认 RDP 桌面上真的出现了 Antigravity 窗口，并检查内置语言服务日志。只有进程存在，不能证明图形应用已经可以使用。

Syncthing 和 Pika Backup 解决的是两件事

最后我安装了 Syncthing 和 Pika Backup。

Syncthing 设置为当前用户登录后自动启动，管理界面只监听 127.0.0.1。它适合在多台电脑之间同步工作目录，但同步删除和错误修改也可能传播到其他设备。

Pika Backup 用来做独立备份。它仍然需要选择外置硬盘或 NAS 作为备份仓库，不能因为应用已经安装，就认为数据已经安全。

我准备采用的分工是：

• Syncthing 负责设备间同步，并开启文件版本控制；
• Pika Backup 负责定期备份到另一块存储设备；
• Git 负责项目版本历史；
• 重要账号和密钥不进入同步文章或公开仓库。

一次系统体检发现了什么

完成安装以后，我又做了一次只读检查。

比较正常的部分包括：

• 32GB 内存仍有较大余量；
• 8GB ZRAM 正常，检查时没有使用交换空间；
• Btrfs 已启用 Zstd 压缩；
• SSD 使用异步 discard，并启用每周 TRIM；
• RX 6700 正在使用开源 amdgpu；
• Wi-Fi 省电已经关闭；
• 固件没有可用更新。

systemd-analyze 一度显示启动用了十一分钟，但日志证明其中约十分钟是在等待输入 LUKS 磁盘密码。磁盘解锁以后，系统进入图形桌面只用了大约九秒。所以这不是 Fedora 启动缓慢，而是加密磁盘在等待人工解锁。

如果以后希望断电重启后仍能完全无人值守，可以研究 TPM2 自动解锁。但这会改变安全边界，必须先保存恢复密钥、确认 PCR 策略，并保留现场恢复手段，不能只为了缩短启动数字就直接开启。

检查还发现 ChatGPT 和 Codex 的多个进程会占用数 GB 内存。32GB 内存目前可以承受，但不用时完全退出，比继续调整 swappiness 更有效。

下一步还需要做什么

这台机器已经可以使用，但还有几项工作值得继续：

1. 安装现有 Fedora 安全和浏览器更新；
2. 把 Clash 改为只监听本机；
3. 不使用 Mullvad 时关闭它的常驻服务；
4. 清理失败但不影响使用的 Bluetooth OBEX 服务；
5. 备份 xrdp 配置后，单独测试 xorgxrdp-glamor；
6. 为 Pika Backup 选择真正独立的备份目标；
7. 给 Syncthing 共享目录设置文件版本控制。

我不会继续为了“优化”去修改已经正常工作的 ZRAM、Btrfs、TRIM 或 AMD 驱动。系统调优应该从实际瓶颈出发：远程桌面是软件渲染，就处理远程渲染；代理端口暴露，就收紧监听范围；内存被不用的软件占用，就减少常驻进程。

我的结论

把 Fedora 安装起来很快，把它变成一台可以长期远程使用的开发机，需要处理的却是系统边界。

显示器、睡眠和图形会话是三件事；代理连接、系统代理和应用流量是三件事；同步、备份和 Git 版本历史也不是同一种保护。

这次排障最有用的方法，不是看到错误就重装，而是先判断问题属于哪一层：图形会话、系统服务、设备权限、代理出口、应用沙盒还是远端服务。只改当前这一层，并在修改后验证真实窗口、监听地址、服务状态和最终访问结果，Linux 桌面就会从“能启动”逐渐变成“可以长期使用”。

本文根据实际安装和排障记录整理，AI 协助梳理结构；内网地址、代理节点、访问密钥和账号信息均未写入文章。