在 Linux 桌面环境中使用 RustDesk 远程连接 Windows 时，遇到了一个比较特殊的剪贴板问题：
- 从远程 Windows 复制文字，可以正常粘贴到 Linux；
- 从本地 Linux 复制文字，却无法粘贴到远程 Windows；
- 远程画面、键盘和鼠标操作均正常；
- 问题仅发生在剪贴板从 Linux 向 Windows 传递的方向。
这种“单向正常、反向失败”的现象，容易被误认为是 Windows 剪贴板服务异常，或者 RustDesk 的剪贴板权限没有打开。但进一步排查后发现，真正的问题位于 Linux 客户端一侧，并且与 KDE Plasma Wayland 环境及 RustDesk 版本有关。
一、问题环境
发生问题的本地系统为 Arch Linux，桌面环境使用 KDE Plasma，当前会话类型为 Wayland。
远程端是一台 Windows 系统，通过 RustDesk 进行远程控制。
首先检查 Linux 当前的图形会话类型和 RustDesk 安装情况：
echo "会话类型：$XDG_SESSION_TYPE"
printf 'RustDesk 命令：'
command -v rustdesk
printf 'RustDesk 版本：'
rustdesk --version 2>/dev/null || true
printf '\nPacman 软件包：\n'
pacman -Q | grep -i rustdesk || true
printf '\nFlatpak 软件包：\n'
flatpak list 2>/dev/null | grep -i rustdesk || true
输出结果显示：
会话类型：wayland
RustDesk 命令：/usr/bin/rustdesk
RustDesk 版本：1.4.7
Pacman 软件包：
rustdesk 1.4.7-1
这说明当前使用的是系统软件包方式安装的 RustDesk 1.4.7，并不是 Flatpak 版本。
二、为什么问题只发生在一个方向
远程桌面的剪贴板同步并不是一个完全对称的过程。
当从 Windows 复制文字到 Linux 时，RustDesk 的 Windows 被控端负责读取 Windows 剪贴板，再通过远程连接发送给 Linux。这个方向能够正常工作，说明：
- RustDesk连接本身正常；
- Windows 端剪贴板权限大概率已经启用；
- 网络传输和远程会话没有明显异常。
而从 Linux 复制文字到 Windows 时，需要 Linux 上的 RustDesk 主动读取本地剪贴板内容。
在 Wayland 环境中，应用程序不能像传统 X11 环境那样随意读取全局剪贴板。剪贴板访问需要依赖 Wayland 协议、桌面环境提供的数据控制接口，以及应用自身对相关协议的支持。
因此，旧版本 RustDesk 可能出现以下情况：
- Linux 用户在 KDE Wayland 应用中复制文字；
- 系统剪贴板本身已经更新；
- RustDesk 没有正确取得这次剪贴板变化；
- 新内容没有发送到远程 Windows；
- Windows 中按下
Ctrl+V时，仍然没有可粘贴的新内容。
这就形成了典型的单向剪贴板故障。
三、确认 RustDesk 软件包来源
为了确定后续应该使用哪种升级方式，还需要确认 RustDesk 是来自系统仓库、AUR，还是外部手动安装的软件包。
执行：
if pacman -Qm rustdesk >/dev/null 2>&1; then
echo "RustDesk 是 AUR/外部软件包"
else
echo "RustDesk 来自已配置的软件仓库"
fi
pacman -Qi rustdesk | grep -E '^(Name|Version|Packager|Install Date)'
输出结果为：
RustDesk 来自已配置的软件仓库
Name : rustdesk
Version : 1.4.7-1
Packager : lilac
由此可以确认，RustDesk 是通过已配置的 Arch Linux 软件仓库安装的。
这意味着不需要引入 Flatpak，也不需要同时保留多个 RustDesk版本。优先使用原有软件包管理方式升级即可。
四、解决方法：升级 RustDesk
针对这种 KDE Plasma Wayland 下的剪贴板兼容问题，最直接的处理方式是将 RustDesk 从 1.4.7 升级到包含后续 Wayland 剪贴板改进的新版本。
由于使用的是 Arch Linux 系统，不建议只刷新软件包数据库后单独安装某一个软件包，例如：
sudo pacman -Sy rustdesk
这种操作可能造成系统处于部分升级状态，不符合 Arch Linux 的软件包维护方式。
正确做法是执行完整系统更新：
sudo pacman -Syu
更新完成后检查 RustDesk版本：
rustdesk --version
pacman -Q rustdesk
如果仓库已经同步了新版，RustDesk 应升级到较新的版本。
五、升级后必须彻底重启 RustDesk
仅升级软件包并不代表当前正在运行的 RustDesk 进程会自动切换到新版本。
升级结束后，应完成以下操作：
- 断开当前 RustDesk远程会话；
- 从 KDE 系统托盘彻底退出 RustDesk；
- 检查旧进程是否已经结束；
- 重新启动 RustDesk；
- 再次连接 Windows；
- 在 Linux 中复制一段全新的文字；
- 在 Windows 记事本中按
Ctrl+V测试。
可以使用下面的命令检查是否仍有 RustDesk 进程：
pgrep -a rustdesk
如果托盘退出后仍然存在旧进程，可以先正常结束它，再重新启动客户端：
pkill rustdesk
rustdesk
不建议在远程任务正在执行时随意终止 Windows 上的 RustDesk 服务。这里需要重启的是 Linux 本地控制端客户端，而不是远程 Windows 主机。
六、测试时应复制全新的内容
剪贴板测试时，不要始终复制同一句话。
某些剪贴板监听机制只在内容发生变化时触发。如果连续复制完全相同的文本，RustDesk 或桌面剪贴板管理器可能不会将其识别为新的变化。
可以依次测试：
clipboard-test-001
clipboard-test-002
clipboard-test-003
每次都在 Linux 复制不同内容，再到 Windows 中粘贴。
最好分别从以下应用测试：
- Konsole；
- 浏览器；
- 文本编辑器；
- KDE 原生应用。
如果只有个别应用复制失败，而其他应用正常，问题可能进一步与该应用使用 Wayland 还是 XWayland 有关。
七、为什么没有优先排查 Windows
这次故障中，Windows 端并不是首要怀疑对象。
原因是 Windows 复制到 Linux 已经能够正常工作。这至少说明：
- Windows 剪贴板可以被 RustDesk读取；
- RustDesk剪贴板权限并没有完全关闭；
- 远程通信链路能够传输剪贴板数据；
- Windows 剪贴板服务没有整体失效。
如果 RustDesk 的“允许剪贴板”权限被完全关闭，通常两个方向都会受到影响，而不是只影响 Linux 到 Windows 的方向。
因此，排查重点应该放在 Linux 本地 RustDesk 如何读取 Wayland 剪贴板，而不是一开始就在 Windows 中重启服务、修改注册表或更改远程桌面设置。
八、备用检查项目
如果升级后仍未恢复，可以继续检查以下项目。
1. RustDesk 剪贴板开关
检查远程连接窗口中是否启用了类似以下选项：
Disable clipboard
如果启用了该选项，应将其关闭。
同时检查 Windows 被控端 RustDesk 的权限设置，确认剪贴板功能处于允许状态。
2. KDE 剪贴板管理器
KDE Plasma 通常会运行 Klipper 剪贴板管理器。可以确认复制的新内容是否已经出现在 Klipper 历史记录中。
如果内容已经出现在 Klipper 中，但 Windows 仍然无法粘贴，说明 KDE 剪贴板本身正常，问题仍然位于 RustDesk 的剪贴板读取和传输环节。
3. XWayland 应用对比
可以分别从 Wayland 原生应用和 XWayland 应用中复制文字。
如果 XWayland 应用复制的文字可以传到 Windows，而 Wayland 原生应用不行，就更能说明问题与 Wayland 数据控制协议兼容有关。
4. 文本与文件需要分别测试
文本剪贴板和文件复制并不是完全相同的功能。
即使文字可以正常双向同步，也不代表 Linux 与 Windows 之间能够直接通过 Ctrl+C、Ctrl+V 传递文件。
如果需要传输文件，应该优先使用 RustDesk 自带的文件传输功能，或者使用 SSH、SFTP、共享目录等更稳定的方式。
九、最终结论
本次问题的核心并不是网络，也不是 Windows 剪贴板故障，而是以下环境组合带来的兼容性问题：
KDE Plasma
+ Wayland
+ Linux 端 RustDesk 1.4.7
+ Linux 向 Windows 发送剪贴板
排查过程中最关键的信息是剪贴板同步具有明显的方向性：
- Windows 到 Linux 正常；
- Linux 到 Windows 失败。
这个差异说明远程连接和 Windows 权限并未整体失效，问题更可能出在 Linux 客户端读取 Wayland 剪贴板的环节。
最终处理方案是：
确认 Wayland 会话
→ 检查 RustDesk版本
→ 确认软件包来源
→ 使用 pacman 完整升级
→ 彻底退出并重启 RustDesk
→ 使用全新文本验证双向剪贴板
面对类似问题时，应先观察故障是否具有方向性，再根据数据流方向判断问题位于控制端还是被控端。这样可以避免在正常的一侧进行大量无效修改，也能更快将问题定位到具体桌面协议、软件版本或权限层面。