银河麒麟 V10 单位电脑运维手册

util6大约 41 分钟

银河麒麟 V10 单位电脑运维手册

写作说明

本文面向第一次接触银河麒麟桌面操作系统的使用者，目标不是记录某一次故障，而是沉淀一份可以复用的单位电脑运维手册。

这类电脑和常见个人电脑的使用方式不完全一样。它既有 Linux 系统的命令行、权限、包管理和网络配置机制，又带有国产桌面系统、国产硬件适配、单位内网环境等特点。很多问题不能只按 Windows 的思路处理，也不能完全照搬 Ubuntu 的教程。

本文计划分为三部分：

银河麒麟系统认识与有线内网配置。
有线内网配置完成后，多网络共存时的路由和 DNS 注意事项。
银河麒麟上的软件安装、版本选择、兼容性判断和替代方案。

当前已完成第一章、第二章和第三章。

第一章：银河麒麟系统认识与有线内网配置

1.1 系统基本画像

本次运维对象是一台单位配发的银河麒麟桌面电脑。根据已有排查记录，系统信息大致如下：

项目	已知信息
操作系统	银河麒麟桌面操作系统 V10 SP1
系统类型	Linux 桌面发行版
桌面环境	UKUI
包管理工具	apt / dpkg
服务管理	systemd
网络管理	NetworkManager
DNS 管理	systemd-resolved
CPU 架构	aarch64 / ARM64
内核版本	5.4.18-27-generic
glibc 版本	2.31
Python 版本	3.8.2
GCC 版本	9.3.0

这些信息非常重要。后续无论是配置网络、安装软件，还是排查兼容性问题，都要先确认系统版本、CPU 架构和基础库版本。

特别要注意的是：

CPU 架构：aarch64 / ARM64
glibc：2.31

这两个信息决定了很多软件能不能安装、能不能启动。很多 Linux 软件虽然提供 .deb 安装包，但默认只支持 x86_64，或者要求更高版本的 glibc。这样的软件即使能下载，也不一定能在这台电脑上运行。

1.2 它和 Ubuntu、Windows、macOS 的差异

1.2.1 和 Ubuntu 的相似点

银河麒麟 V10 在使用体验上有一部分接近 Debian / Ubuntu 系 Linux 系统：

sudo apt update
sudo apt install <软件包>
sudo dpkg -i <软件包.deb>
systemctl status <服务名>
ip addr
ip route
nmcli connection show

也就是说，它同样有：

apt 包管理
dpkg 安装 .deb
systemd 服务管理
NetworkManager 网络管理
Linux 文件系统结构
普通用户 / root 权限模型

因此，在处理网络、服务、日志、权限时，可以参考 Linux 的通用方法。

1.2.2 和 Ubuntu 的差异

但它不能简单当成 Ubuntu 使用。主要差异在于：

对比项	Ubuntu	银河麒麟 V10
软件源	Ubuntu 官方源	麒麟官方源、单位可能定制源
软件版本	社区更新较快	更偏稳定和国产环境适配
桌面环境	GNOME 常见	UKUI 常见
硬件适配	以主流 PC 为主	常见国产 CPU、国产整机适配
软件兼容	x86_64 软件生态丰富	ARM64 环境下软件选择更窄
外部教程适用性	大量教程可直接使用	需要先判断版本和架构

尤其不能随意把 Ubuntu 20.04、22.04 的软件源加入银河麒麟。这样可能导致依赖库混乱，严重时会破坏系统包管理。

1.2.3 和 Windows 的差异

Windows 用户刚接触银河麒麟时，最容易不适应的是：

软件不是随便下载 exe 安装
很多系统配置不在图形界面里
网络状态不能只看右下角图标
修改系统文件需要 sudo 权限
服务启动、停止、开机自启由 systemd 管理
网络配置可能由 NetworkManager 动态生成

在 Windows 上，看到“已连接”通常会以为网络已经完整可用。但在银河麒麟上，“已连接”只能说明底层连接状态正常，不代表 DNS、路由、业务系统访问都正常。

举例来说：

网关能 ping 通
不等于业务网站能访问

IP 地址存在
不等于跨网段路由存在

图形界面显示已连接
不等于 DNS 配置正确

1.2.4 和 macOS 的差异

macOS 也是类 Unix 系统，但银河麒麟的运维方式仍然明显不同：

对比项	macOS	银河麒麟 V10
包管理	Homebrew 常见	apt / dpkg
服务管理	launchd	systemd
网络命令	ifconfig、networksetup	ip、nmcli、resolvectl
图形生态	商业桌面软件丰富	国产化、Linux 软件、Web 应用更多
软件安装	dmg、pkg、brew	deb、apt、AppImage、源码或脚本

macOS 用户容易习惯“图形界面优先”，但在银河麒麟上，命令行输出往往更准确。

1.3 有线内网配置的核心模型

单位内网配置不能只看“能不能上网”这一个结果，要拆成几个层级。

本次已知的有线内网配置如下：

项目	值
有线接口	`enaphyt4i0`
连接名称	`有线连接 1`
本机地址	`10.32.98.120/24`
内网网关	`10.32.98.254`
内网 DNS	`10.30.255.1`
业务域名	`ips.sx.hsip.gov.cn`
业务地址	`10.30.20.107`

这里有一个关键点：本机地址和目标业务地址不在同一个网段。

本机地址：

10.32.98.120/24

本机直连网段：

10.32.98.0 - 10.32.98.255

业务系统地址：

10.30.20.107

所以访问业务系统需要两步：

第一步：通过内网 DNS 把域名解析为 10.30.20.107
第二步：通过内网网关 10.32.98.254 转发到 10.30.0.0/16 网段

如果只配置了本机 IP 和网关，但没有正确配置 DNS 或静态路由，就会出现：

网关能 ping 通
部分资源能访问
指定业务系统打不开

1.4 首次配置内网时必须检查的内容

首次配置内网时，不应该只让图形界面显示“已连接”就结束。至少要检查以下内容。

1.4.1 确认接口名称

ip link
nmcli device status

记录有线接口名称。例如本次是：

enaphyt4i0

不同电脑的接口名可能不同，不能照抄。

1.4.2 确认连接名称

nmcli connection show

记录当前连接名称。例如：

有线连接 1

后续修改配置时，命令中的连接名称必须和实际输出一致。

1.4.3 确认 IP 地址

ip addr show enaphyt4i0

期望看到：

inet 10.32.98.120/24

如果没有 inet 地址，说明静态 IP 没有真正应用到接口上。

1.4.4 确认 NetworkManager 配置

nmcli connection show "有线连接 1"

重点检查：

ipv4.method
ipv4.addresses
ipv4.gateway
ipv4.dns
ipv4.routes

这一步比看图形界面更可靠。

1.4.5 确认网关可达

ping -c 3 10.32.98.254

网关可达只能说明第一跳正常。它是必要条件，但不是业务系统可用的充分条件。

1.4.6 确认内网 DNS 可达

ping -c 3 10.30.255.1

如果 ping 不通，还要进一步检查路由：

ip route get 10.30.255.1

1.4.7 确认业务域名解析

nslookup ips.sx.hsip.gov.cn 10.30.255.1

期望结果中包含：

Address: 10.30.20.107

如果指定内网 DNS 能解析，但系统默认解析失败，说明系统 DNS 配置没有正确使用内网 DNS。

1.4.8 确认目标业务地址路由

ip route get 10.30.20.107

理想结果类似：

10.30.20.107 via 10.32.98.254 dev enaphyt4i0 src 10.32.98.120

如果没有通过 10.32.98.254，就要补静态路由。

1.4.9 确认业务页面响应

curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/"

如果修复成功，应能看到类似：

HTTP/1.1 200

1.5 推荐的内网持久化配置

以下命令用于把关键配置写进 NetworkManager，而不是只临时生效。

1.5.1 设置静态地址

sudo nmcli connection modify "有线连接 1" ipv4.method manual
sudo nmcli connection modify "有线连接 1" ipv4.addresses "10.32.98.120/24"

1.5.2 设置内网 DNS

sudo nmcli connection modify "有线连接 1" ipv4.dns "10.30.255.1"
sudo nmcli connection modify "有线连接 1" ipv4.dns-search "hsip.gov.cn"

1.5.3 设置到业务网段的静态路由

sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"

这条配置的含义是：

访问 10.30.0.0/16 时，交给 10.32.98.254 转发

这是访问 ips.sx.hsip.gov.cn 的关键配置之一。

1.5.4 重新激活连接

sudo nmcli connection down "有线连接 1"
sudo nmcli connection up "有线连接 1"

激活后立即检查：

ip addr show enaphyt4i0
ip route
nmcli connection show "有线连接 1"

1.6 为什么重启后原本正常的配置会发生变化

这是本次事件中最值得记录的地方。

Linux 系统重启后，运行时网络状态会被清空。NetworkManager 启动后，只会根据已经持久化保存的连接配置重新建立网络。

如果配置人员在首次配置时执行了临时命令，例如：

sudo ip route add 10.30.0.0/16 via 10.32.98.254

这条路由会立即生效，但它只是运行时状态。只要没有写入 NetworkManager 的连接配置，重启后就会丢失。

同理，DNS 也可能出现类似问题。银河麒麟 V10 使用 NetworkManager 和 systemd-resolved 管理域名解析。/etc/resolv.conf 往往不是手工维护的静态文件，而是系统服务动态生成的文件。

如果内网 DNS 没有写进连接配置，重启后系统重新生成 DNS 状态时，就可能不再使用：

10.30.255.1

因此，第一次重启后的实际状态可能是：

本机地址恢复了
网关可达
部分内网资源可访问
内网 DNS 没有正确恢复
跨网段静态路由没有正确恢复

这就是为什么会出现：

网关能 ping 通
部分资源能进入
ips.sx.hsip.gov.cn 不能访问

还有一种情况也需要注意：同一个有线接口可能存在多个 NetworkManager 连接 profile。图形界面显示“已连接”，并不代表当前激活的一定是单位配置好的完整连接。它可能只是一个自动生成的基础连接。

因此，判断网络是否真正恢复，不能只看图形界面，而要看：

ip addr
ip route
nmcli connection show
resolvectl status
curl

1.7 遇到内网问题时的排查顺序

遇到业务系统打不开时，不要一开始就怀疑浏览器或网站。建议按下面顺序排查。

第一步：确认接口是否有地址

ip addr show enaphyt4i0

看是否有：

inet 10.32.98.120/24

第二步：确认当前路由表

ip route

重点找：

10.30.0.0/16 via 10.32.98.254 dev enaphyt4i0

第三步：确认访问目标会走哪条路

ip route get 10.30.20.107

这条命令比直接看完整路由表更直观。

第四步：确认 DNS

resolvectl status
resolvectl dns
nslookup ips.sx.hsip.gov.cn
nslookup ips.sx.hsip.gov.cn 10.30.255.1

如果指定 10.30.255.1 可以解析，默认解析不行，问题就在系统 DNS 配置或 DNS 分流。

第五步：确认目标服务是否响应

curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/"

如果 DNS 已经能解析，路由也正确，但 HTTP 不响应，再考虑目标服务、端口、防火墙或业务系统本身的问题。

第六步：检查防火墙

sudo iptables -L -n --line-numbers
sudo ufw status
systemctl status firewalld --no-pager

本次排查记录中，本机防火墙不是主要原因。更关键的是 DNS 和路由。

1.8 临时修复和长期修复的区别

临时修复

临时修复可以用于快速验证判断是否正确：

sudo ip route add 10.30.0.0/16 via 10.32.98.254

它的优点是立即生效。缺点是重启后会丢失。

长期修复

长期修复必须写入 NetworkManager：

sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"

然后重启连接：

sudo nmcli connection down "有线连接 1"
sudo nmcli connection up "有线连接 1"

再验证：

ip route | grep "10.30.0.0/16"

1.9 hosts 兜底方案

如果内网 DNS 分流不稳定，而业务地址相对固定，可以用 /etc/hosts 做兜底：

10.30.20.107 ips.sx.hsip.gov.cn

操作前先备份：

sudo cp /etc/hosts /etc/hosts.bak.$(date +%Y%m%d)

写入记录：

sudo sh -c 'echo "" >> /etc/hosts'
sudo sh -c 'echo "# 内网业务系统" >> /etc/hosts'
sudo sh -c 'echo "10.30.20.107 ips.sx.hsip.gov.cn" >> /etc/hosts'

验证：

grep "ips.sx.hsip.gov.cn" /etc/hosts
curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/"

需要注意：hosts 是强绑定。如果将来业务系统地址变化，这条记录也要同步修改。

1.10 首次配置后建议保存的信息

为了以后排查和迁移，建议首次配置完成后立即保存这些信息。

mkdir -p ~/network-backup

cat /etc/os-release > ~/network-backup/os-release.txt
uname -a > ~/network-backup/uname.txt
arch > ~/network-backup/arch.txt
ldd --version > ~/network-backup/glibc.txt 2>&1

ip addr > ~/network-backup/ip-addr.txt
ip route > ~/network-backup/ip-route.txt
nmcli device status > ~/network-backup/nmcli-device-status.txt
nmcli connection show > ~/network-backup/nmcli-connection-show.txt
nmcli connection show "有线连接 1" > ~/network-backup/wired-connection.txt
resolvectl status > ~/network-backup/resolvectl-status.txt
cat /etc/hosts > ~/network-backup/hosts.txt

如果要打包带走：

tar -czf network-backup-$(date +%Y%m%d).tar.gz ~/network-backup

1.11 需要从工作电脑补充采集的信息

由于本文是在另一台电脑上编写，无法直接读取工作电脑的实时配置。为了把本文从“经验总结”补成“精确手册”，需要从工作电脑采集以下信息。

系统信息

cat /etc/os-release
cat /etc/kylin-release 2>/dev/null
uname -a
arch
lsb_release -a 2>/dev/null
ldd --version
gcc --version 2>/dev/null | head -1
python3 --version
systemctl --version | head -1

硬件信息

lscpu
free -h
df -h
lsblk
lspci 2>/dev/null
lsusb 2>/dev/null

网络信息

ip addr
ip route
nmcli device status
nmcli connection show
nmcli connection show "有线连接 1"
resolvectl status
resolvectl dns
cat /etc/resolv.conf
cat /etc/hosts

业务系统测试信息

nslookup ips.sx.hsip.gov.cn
nslookup ips.sx.hsip.gov.cn 10.30.255.1
ip route get 10.30.20.107
ping -c 3 10.32.98.254
ping -c 3 10.30.255.1
curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/" 2>&1 | head -40

防火墙信息

sudo iptables -L -n --line-numbers
sudo iptables -t nat -L -n --line-numbers
sudo ufw status
systemctl status firewalld --no-pager 2>/dev/null

拿到这些输出后，可以继续补全本文中的系统信息表，并把命令示例改成更贴近工作电脑实际状态的版本。

1.12 本章结论

银河麒麟 V10 的有线内网配置不能只看图形界面，也不能只看网关是否能 ping 通。

一个业务系统能否访问，至少要同时确认：

接口有正确 IP
连接 profile 保存了正确配置
DNS 能解析业务域名
路由能到达目标网段
目标服务有应用层响应

本次问题的核心经验是：

重启后出问题，往往不是基础连接完全丢失，而是临时 DNS、临时路由或不完整连接 profile 没有被 NetworkManager 持久化恢复。

因此，首次配置完成后一定要做两件事：

把关键配置写入 NetworkManager
把当前可用状态导出备份

这样以后重启、更换电脑或再次排查时，才有明确依据。

第二章：USB WiFi 网卡驱动安装与内外网双网共存

2.1 本章目标

第一章解决的是有线内网本身如何稳定工作。第二章讨论的是另一个常见需求：在有线内网已经配置好的前提下，再通过一个 USB WiFi 网卡连接外部网络，使电脑同时具备：

内网业务系统可访问
外部网络可访问
两者互不抢路由
重启后配置仍然可恢复

这件事不能简单理解为“插上网卡、连上热点”。

2.2 这类 USB WiFi 驱动安装的两个关键点

我对这类驱动安装的理解是两个步骤：

第一步：补齐银河麒麟系统缺少的编译和内核环境
第二步：执行驱动包提供的安装流程

这个顺序不能反过来。

如果系统缺少 make、gcc、内核头文件或 /lib/modules/$(uname -r)/build，即使运行驱动安装脚本，也可能在编译内核模块时失败。

如果环境已经补齐，驱动包里的安装流程才有机会完成这些动作：

复制固件到 /lib/firmware
复制 udev 规则到 /etc/udev/rules.d
编译内核模块
安装内核模块到 /lib/modules
加载模块
让 NetworkManager 识别新无线接口

2.3 驱动包目录结构

这次驱动包大致包含以下内容：

Linux/
├── release_note.txt
├── linux_driver_package/
│   ├── aic8800d80fdrvpackage.deb
│   └── AX900 Deb驱动安装教程_Linux_V3.0.pdf
├── aic8800_linux_driver/
│   ├── install_setup.sh
│   ├── uninstall_setup.sh
│   ├── tools/aic.rules
│   ├── fw/aic8800D80/
│   └── drivers/aic8800/
├── AX900 驱动安装教程_Linux_V3.0.pdf
├── Kali-23.2-linux-headers-6.1.0.sh
└── Kali-24.2-linux-headers-6.6.15.sh

其中最重要的是：

文件或目录	作用
`aic8800d80fdrvpackage.deb`	Debian 格式驱动安装包，会触发编译和安装流程
`aic8800_linux_driver/install_setup.sh`	复制固件和 udev 规则，触发设备重新识别
`aic8800_linux_driver/uninstall_setup.sh`	清理固件和 udev 规则
`aic8800_linux_driver/fw/aic8800D80/`	网卡固件
`aic8800_linux_driver/tools/aic.rules`	udev 规则，用于处理设备初始识别
`aic8800_linux_driver/drivers/aic8800/`	驱动源码

需要注意：当前这份 install_setup.sh 并不是完整的编译安装脚本。它主要做这些事：

cp -rf ./fw/aic8800D80 /lib/firmware/
cp ./tools/aic.rules /etc/udev/rules.d
udevadm trigger
udevadm control --reload
eject /dev/aicudisk

真正负责源码编译和模块安装的，是 .deb 包安装时执行的 postinst 流程。这个流程会进入：

/usr/src/AIC8800/drivers/aic8800/

然后执行：

make
make install
modprobe cfg80211
insmod aic_load_fw.ko
insmod aic8800_fdrv.ko

所以实际操作时，优先推荐使用 .deb 包安装；install_setup.sh 更像是固件和 udev 规则补充步骤。

2.4 安装前必须确认的系统环境

驱动包需要编译内核模块。安装前先确认以下信息。

2.4.1 确认系统版本和架构

cat /etc/os-release
cat /etc/kylin-release 2>/dev/null
uname -a
uname -r
arch

重点看：

系统是否为银河麒麟 V10
CPU 架构是否为 aarch64 / arm64
当前内核版本是多少

2.4.2 确认编译工具是否存在

which gcc
which make
gcc --version
make --version

如果没有，先安装基础编译工具：

sudo apt update
sudo apt install -y gcc make build-essential

如果 build-essential 在麒麟源里不可用，可以先尝试：

sudo apt install -y gcc make libc6-dev

2.4.3 确认内核头文件是否存在

驱动 Makefile 使用的内核构建目录是：

/lib/modules/$(uname -r)/build

检查命令：

ls -ld /lib/modules/$(uname -r)/build

如果这个路径不存在，说明缺少当前内核对应的 headers 或 build 目录。驱动编译大概率会失败。

继续查看当前内核模块目录：

ls /lib/modules/$(uname -r)

检查已安装的 headers：

dpkg -l | grep -E "linux-headers|kernel-headers|kylin.*headers"

尝试从麒麟源安装：

sudo apt update
sudo apt install -y linux-headers-$(uname -r)

如果提示找不到包，不要急着添加 Ubuntu 或 Kali 的源。应该优先从以下位置找匹配当前内核的包：

麒麟官方源
单位内网软件源
随机器提供的离线包
厂商提供的适配包

原因是：内核模块必须和当前正在运行的内核版本匹配。内核头文件版本不匹配，即使能编译，也可能无法加载。

2.4.4 不建议直接使用 Kali headers 脚本

驱动目录里有：

Kali-23.2-linux-headers-6.1.0.sh
Kali-24.2-linux-headers-6.6.15.sh

这两个脚本是给 Kali 特定内核版本准备的。银河麒麟 V10 当前已知内核是：

5.4.18-27-generic

如果当前内核不是 Kali 的 6.1.0 或 6.6.15，就不要直接执行这些脚本。否则可能安装一套和当前系统不匹配的 headers。

正确原则是：

uname -r 是什么版本，就找什么版本的 headers/build 环境

2.5 安装驱动的推荐流程

以下流程适合在工作电脑上执行。执行前建议先进入驱动目录：

cd ~/Downloads/麒麟系统_USB无线网卡驱动_V9/Linux

2.5.1 安装前备份状态

mkdir -p ~/driver-install-backup

uname -a > ~/driver-install-backup/uname-before.txt
arch > ~/driver-install-backup/arch-before.txt
ip addr > ~/driver-install-backup/ip-addr-before.txt
ip route > ~/driver-install-backup/ip-route-before.txt
nmcli device status > ~/driver-install-backup/nmcli-device-before.txt
lsusb > ~/driver-install-backup/lsusb-before.txt 2>/dev/null
lsmod > ~/driver-install-backup/lsmod-before.txt

2.5.2 先确认设备能被 USB 层看到

插入 USB WiFi 网卡后执行：

lsusb
dmesg | tail -80

如果 lsusb 里完全看不到新设备，先排查 USB 接口、设备本身和供电。

如果 USB 层能看到设备，但 nmcli device status 没有出现无线设备，通常就是驱动或固件没有正确加载。

2.5.3 安装 `.deb` 驱动包

优先使用驱动包提供的 .deb：

cd ~/Downloads/麒麟系统_USB无线网卡驱动_V9/Linux/linux_driver_package
sudo dpkg -i aic8800d80fdrvpackage.deb

如果提示依赖缺失：

sudo apt --fix-broken install

然后再次执行：

sudo dpkg -i aic8800d80fdrvpackage.deb

这一步会触发驱动包内部脚本，尝试编译并加载：

aic_load_fw.ko
aic8800_fdrv.ko

2.5.4 视情况执行固件脚本

如果 .deb 安装后设备仍未识别，可以再执行固件和 udev 规则脚本：

cd ~/Downloads/麒麟系统_USB无线网卡驱动_V9/Linux/aic8800_linux_driver
chmod +x install_setup.sh
sudo ./install_setup.sh

这个脚本会复制：

fw/aic8800D80 -> /lib/firmware/aic8800D80
tools/aic.rules -> /etc/udev/rules.d/aic.rules

并触发：

udevadm trigger
udevadm control --reload

2.5.5 重插设备或重启

驱动和 udev 规则安装后，建议先重插设备。

如果仍未出现无线接口，再重启系统：

sudo reboot

重启后检查：

lsmod | grep -E "aic|cfg80211"
nmcli device status
ip link
dmesg | grep -i -E "aic|firmware|wlan|usb" | tail -80

2.6 驱动安装成功的判断标准

不要只看安装命令是否结束。要用下面几个标准判断。

2.6.1 模块存在

lsmod | grep -E "aic8800|aic_load|cfg80211"

或者查看模块安装目录：

find /lib/modules/$(uname -r) -name "*aic*.ko"

2.6.2 固件存在

ls /lib/firmware/aic8800D80

应能看到类似：

fmacfw_8800d80_u02.bin
fw_patch_8800d80_u02.bin
lmacfw_rf_8800d80_u02.bin

2.6.3 udev 规则存在

cat /etc/udev/rules.d/aic.rules

规则里会出现类似：

ATTRS{idVendor}=="a69c"

它的作用是处理部分 USB WiFi 设备初始以“存储设备”形态出现的问题，通过 eject 让设备切换到网卡模式。

2.6.4 NetworkManager 识别无线接口

nmcli device status

期望出现一个无线类型设备，例如：

DEVICE            TYPE      STATE
wlx...            wifi      disconnected

接口名称不一定固定，可能是：

wlan0
wlx688fc9592dbc

后续命令应以实际输出为准。

2.7 外网连接配置

驱动安装成功后，NetworkManager 应该能看到新的无线接口。先确认设备状态：

nmcli device status
ip addr show wlx688fc9592dbc

扫描可用网络：

nmcli device wifi list

连接外部网络：

nmcli device wifi connect "SSID名称" password "密码" ifname wlx688fc9592dbc

连接成功后检查 DHCP 获取到的地址、网关和 DNS：

nmcli -f IP4,GENERAL device show wlx688fc9592dbc
ip route
resolvectl dns

本次实测外部网络配置如下：

项目	值
接口	`wlx688fc9592dbc`
类型	WiFi
IP 地址	`172.16.2.199/22`
网关	`172.16.0.1`
路由 metric	`600`
用途	互联网访问

外部网络配置成功后，应当看到默认路由：

default via 172.16.0.1 dev wlx688fc9592dbc metric 600

验证外部网络：

curl -s --connect-timeout 5 --noproxy '*' "https://www.baidu.com" -o /dev/null -w "%{http_code}\n"

期望：

2.8 双网共存的目标拓扑

双网共存不是让两个网络随便同时连接，而是要明确分工。

本次单位电脑的目标拓扑是：

接口	类型	IP 地址	网关	用途
`enaphyt4i0`	有线内网	`10.32.98.120/24`	`10.32.98.254`	山西省医保信息平台
`wlx688fc9592dbc`	WiFi 外网	`172.16.2.199/22`	`172.16.0.1`	互联网

目标路由表应当类似：

default via 172.16.0.1 dev wlx688fc9592dbc metric 600
10.30.0.0/16 via 10.32.98.254 dev enaphyt4i0 metric 50
10.32.98.0/24 dev enaphyt4i0 metric 50
172.16.0.0/22 dev wlx688fc9592dbc metric 600

核心原则：

外网负责 default 默认路由
内网负责 10.30.0.0/16 和 10.32.98.0/24
内网连接不接管默认网关
内网业务域名使用内网 DNS

如果两个连接都抢默认路由，就会出现：

外网断
内网页面断
或者浏览器一会儿能打开、一会儿打不开

2.9 双网共存的 NetworkManager 配置

2.9.1 有线内网使用静态 IP

有线内网不启用 DHCP，使用单位指定的静态地址：

sudo nmcli connection modify "有线连接 1" ipv4.method manual
sudo nmcli connection modify "有线连接 1" ipv4.addresses "10.32.98.120/24"

内网 DNS：

sudo nmcli connection modify "有线连接 1" ipv4.dns "10.30.255.1"

2.9.2 防止有线内网覆盖默认路由

这是双网共存最关键的配置：

sudo nmcli connection modify "有线连接 1" ipv4.never-default yes

检查：

nmcli connection show "有线连接 1" | grep "ipv4.never-default"

期望：

ipv4.never-default: 是

含义是：有线内网可以访问内网，但不能抢走默认出口。

2.9.3 配置内网路由优先级

有线内网 metric 设置为 50：

sudo nmcli connection modify "有线连接 1" ipv4.route-metric 50

外网接口实测 metric 是 600。这样到内网网段时，有线优先级更高。

内网 metric 50 < 外网 metric 600

这里不要误解：metric 小并不代表有线会抢所有流量。因为有线已经设置 never-default=yes，它不会生成默认路由。metric 只影响匹配到内网路由时的优先级。

2.9.4 固定内网静态路由

sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"

检查：

ip route | grep "10.30.0.0/16"
ip route get 10.30.20.107

期望：

10.30.0.0/16 via 10.32.98.254 dev enaphyt4i0 metric 50
10.30.20.107 via 10.32.98.254 dev enaphyt4i0 src 10.32.98.120

2.9.5 重新激活连接

sudo nmcli connection down "有线连接 1"
sudo nmcli connection up "有线连接 1"

再检查完整路由：

ip route

2.10 DNS 解析链：双网里最核心的问题

双网共存时，真正容易出问题的是 DNS。

本次目标解析链是：

浏览器请求 xxx.sx.hsip.gov.cn
    -> /etc/resolv.conf
    -> 127.0.0.53 (systemd-resolved)
        -> 根据域名路由：
            *.hsip.gov.cn -> Link 4 (enaphyt4i0) -> 内网 DNS 10.30.255.1
            其他域名      -> Link 5 (wlx688fc9592dbc) -> 202.99.192.68 / 223.5.5.5
        -> 返回结果给浏览器
    -> 浏览器判断是否走代理

已知内网 DNS：

项目	值
内网 DNS	`10.30.255.1`
可达性	ping 约 7ms
行为	能解析已配置的内网业务域名，对未知子域名可能返回拒绝

已知可解析域名：

域名	内网 DNS 返回	备注
`ips.sx.hsip.gov.cn`	`10.30.20.107`	主页面，HTTP 200
`xxx.sx.hsip.gov.cn`	`198.18.0.185`	子页面，连通性需继续确认

检查 DNS 的命令：

cat /etc/resolv.conf
resolvectl status
resolvectl dns
nslookup ips.sx.hsip.gov.cn
nslookup ips.sx.hsip.gov.cn 10.30.255.1
nslookup xxx.sx.hsip.gov.cn 10.30.255.1

如果指定 10.30.255.1 能解析，而默认解析失败，说明系统 DNS 链路有问题。

2.11 systemd-resolved 与 dnsmasq 冲突

本机已知存在一个 DNS 冲突点：

systemd-resolved: 127.0.0.53:53
dnsmasq:          127.0.0.1:53

但 /etc/resolv.conf 指向的是：

127.0.0.53

这意味着系统默认使用 systemd-resolved，而不是 dnsmasq。即使 dnsmasq 中配置了：

server=/hsip.gov.cn/10.30.255.1

也可能根本没有被使用。

2.11.1 如何确认谁在监听 53 端口

sudo ss -lntup | grep ':53'
ps -ef | grep -E "dnsmasq|systemd-resolved" | grep -v grep
cat /etc/resolv.conf
resolvectl status

2.11.2 方案 A：统一使用 dnsmasq

如果选择 dnsmasq 作为本机 DNS 分流入口，思路是：

/etc/resolv.conf -> 127.0.0.1
dnsmasq 负责把 hsip.gov.cn 转给 10.30.255.1
其他域名转给外部 DNS

参考配置：

server=/hsip.gov.cn/10.30.255.1
server=/sx.hsip.gov.cn/10.30.255.1
server=202.99.192.68
server=223.5.5.5

这种方案的优点是域名分流直观。缺点是要谨慎处理 systemd-resolved，否则两个 DNS 服务会互相干扰。

修改前必须备份：

cp /etc/resolv.conf ~/resolv.conf.bak.$(date +%Y%m%d)

2.11.3 方案 B：保留 systemd-resolved

如果继续使用 systemd-resolved，就不要指望 dnsmasq 的规则自动生效。需要通过 NetworkManager / resolved 的链路 DNS 规则把内网域名送到有线接口。

检查重点：

resolvectl domain
resolvectl dns
resolvectl query ips.sx.hsip.gov.cn

如果 resolved 对内网域名偶发超时，最稳妥的兜底仍然是 /etc/hosts：

10.30.20.107 ips.sx.hsip.gov.cn

但要注意：如果请求被代理软件接管，代理软件可能不会读取 /etc/hosts。

2.12 代理软件对内网访问的影响

本机已安装多个代理相关组件：

软件	位置	类型	状态
Mihomo Party	`/opt/clash-party/`	GUI 客户端，Electron	运行中

这类代理软件会改变浏览器访问路径。网络层路由正确，不代表浏览器一定直连内网。

2.12.1 Mihomo Party 已知配置特点

已知配置要点：

mixed-port: 7890
mode: rule
enhanced-mode: fake-ip
use-hosts: false
nameserver: DoH
proxy: Hysteria2 远程服务器

当 use-hosts: false 时，Mihomo Party 不读取 /etc/hosts。这非常关键。

如果浏览器请求被送到 Mihomo Party，后续 DNS 解析就不再完全由系统的 /etc/resolv.conf 决定，而是由 Mihomo Party 自己的 DNS 配置决定。

这会导致：

系统 hosts 写了内网域名 -> 直连时有效
请求进入代理软件 -> 代理软件不读 hosts -> hosts 可能失效

2.12.2 fake-ip 与内网域名

Mihomo Party 开启 fake-ip 后，可能给域名返回 198.18.0.0/16 范围内的假 IP。

本次已观察到：

xxx.sx.hsip.gov.cn -> 198.18.0.185

198.18.0.0/16 是代理软件常用的 fake-ip 地址段。这个地址不是业务系统真实地址。

如果内网域名被解析成 fake-ip，再由远程代理处理，内网请求很可能无法到达单位内网。

因此，对内网域名必须设置直连规则。

2.13 系统代理设置与绕过列表

系统代理使用 gsettings 管理。检查命令：

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy.https host
gsettings get org.gnome.system.proxy.https port
gsettings get org.gnome.system.proxy.socks host
gsettings get org.gnome.system.proxy.socks port
gsettings get org.gnome.system.proxy ignore-hosts

已知代理端口：

HTTP:  127.0.0.1:7890
HTTPS: 127.0.0.1:7890
SOCKS: 127.0.0.1:7890

已知绕过列表包含：

localhost
127.0.0.1
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
::1

问题是：绕过列表只有 IP 段时，遇到内网域名不一定可靠。

如果浏览器先把域名交给代理软件，代理软件再返回 fake-ip，例如 198.18.0.185，这个地址不在 10.0.0.0/8，请求就可能继续走代理。

建议把内网域名也加入绕过列表：

gsettings set org.gnome.system.proxy ignore-hosts "['localhost','127.0.0.1','::1','10.0.0.0/8','172.16.0.0/12','192.168.0.0/16','*.hsip.gov.cn','*.sx.hsip.gov.cn']"

设置后重新查看：

gsettings get org.gnome.system.proxy ignore-hosts

2.14 Mihomo Party 规则建议

为了避免内网业务经过远程代理，Mihomo Party 中应添加直连规则。

建议规则：

rules:
  - DOMAIN-SUFFIX,sx.hsip.gov.cn,DIRECT
  - DOMAIN-SUFFIX,hsip.gov.cn,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

DNS 也应给内网域名配置内网 DNS。不同 Mihomo Party 版本界面可能不同，配置思想是：

dns:
  enable: true
  nameserver:
    - https://doh.pub/dns-query
  nameserver-policy:
    "+.sx.hsip.gov.cn": 10.30.255.1
    "+.hsip.gov.cn": 10.30.255.1

如果继续使用 fake-ip，内网域名最好排除 fake-ip。不同客户端对 fake-ip-filter 的展示可能不同，最终以实际解析结果为准。目标是：

内网域名不要返回 198.18.0.0/16 假 IP
内网域名直接解析到真实内网地址
内网域名请求走 DIRECT

验证规则是否生效：

curl -v --connect-timeout 10 "http://ips.sx.hsip.gov.cn/" 2>&1 | head -40
curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/" 2>&1 | head -40

第一条模拟可能经过系统代理的访问，第二条强制绕过代理。两者结果不同，就说明代理链路仍在影响内网访问。

2.15 内外网共存时的常见问题与解决方案

问题一：外网连上后内网打不开

优先检查路由：

ip route
ip route get 10.30.20.107

如果 10.30.20.107 没有走 enaphyt4i0，修复：

sudo nmcli connection modify "有线连接 1" ipv4.never-default yes
sudo nmcli connection modify "有线连接 1" ipv4.route-metric 50
sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"
sudo nmcli connection down "有线连接 1"
sudo nmcli connection up "有线连接 1"

问题二：内网能打开，但外网打不开

检查默认路由：

ip route | grep default

默认路由必须走：

172.16.0.1 dev wlx688fc9592dbc

如果默认路由走了 10.32.98.254，说明有线内网抢了默认网关。重新设置：

sudo nmcli connection modify "有线连接 1" ipv4.never-default yes

然后重启连接。

问题三：命令行能访问内网，浏览器打不开

这通常不是路由问题，而是浏览器代理问题。

对比测试：

curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/"
curl -v --connect-timeout 10 "http://ips.sx.hsip.gov.cn/"

如果 --noproxy '*' 成功，而普通访问失败，说明请求被代理影响。

处理：

系统代理绕过列表加入 *.hsip.gov.cn、*.sx.hsip.gov.cn
Mihomo Party 添加 DOMAIN-SUFFIX,sx.hsip.gov.cn,DIRECT
Mihomo Party DNS 对内网域名使用 10.30.255.1

问题四：内网域名解析成 198.18.x.x

这是 fake-ip 典型现象。

检查：

nslookup xxx.sx.hsip.gov.cn
nslookup xxx.sx.hsip.gov.cn 10.30.255.1

如果系统默认解析得到 198.18.x.x，而指定内网 DNS 得到真实地址，说明代理 DNS 接管了请求。

处理：

内网域名 DIRECT
内网域名使用 10.30.255.1
内网域名排除 fake-ip
必要时临时关闭系统代理再访问内网

问题五：systemd-resolved 偶发超时

检查：

resolvectl query ips.sx.hsip.gov.cn
nslookup ips.sx.hsip.gov.cn 10.30.255.1
sudo ss -lntup | grep ':53'

如果内网 DNS 本身能解析，但 resolved 超时，说明本机 DNS 分流链路不稳定。

可选方案：

短期：对关键域名写 hosts
中期：统一 DNS 入口，只保留 systemd-resolved 或 dnsmasq 中的一个作为主入口
长期：整理单位内网域名清单，统一配置 DNS 分流

问题六：未知子域名被内网 DNS 拒绝

已知内网 DNS 对未知子域名可能返回 REFUSED。如果前端页面动态构造子域名，就会出现主页面能打开、子页面或接口失败。

排查方法：

nslookup 可疑子域名 10.30.255.1
curl -v "http://可疑子域名/"

也可以在浏览器开发者工具的 Network 面板里查看实际访问了哪些域名。

解决思路：

确定具体子域名
让内网 DNS 增加记录
或在本机 hosts 中逐条补充
或修改代理 DNS 规则让这些域名全部走内网 DNS

2.16 双网配置后的总验证清单

2.16.1 接口检查

nmcli device status
ip addr show enaphyt4i0
ip addr show wlx688fc9592dbc

期望：

enaphyt4i0      10.32.98.120/24
wlx688fc9592dbc 172.16.2.199/22

2.16.2 路由检查

ip route
ip route get 10.30.20.107
ip route get 223.5.5.5

期望：

10.30.20.107 -> enaphyt4i0
223.5.5.5    -> wlx688fc9592dbc

2.16.3 DNS 检查

cat /etc/resolv.conf
resolvectl dns
resolvectl domain
nslookup ips.sx.hsip.gov.cn 10.30.255.1

2.16.4 代理检查

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy ignore-hosts
systemctl status mihomo --no-pager
ps -ef | grep -i "mihomo\\|clash-party" | grep -v grep

2.16.5 业务检查

curl -s --connect-timeout 5 --noproxy '*' "https://www.baidu.com" -o /dev/null -w "%{http_code}\n"
curl -s --connect-timeout 5 --noproxy '*' "http://ips.sx.hsip.gov.cn/" -o /dev/null -w "%{http_code}\n"

两个都返回 200，只能说明基础双网可用。浏览器仍要额外确认代理绕过规则是否生效。

2.17 驱动卸载和回退

如果安装后系统异常，先保留日志，再考虑卸载。

2.17.1 卸载 deb 包

dpkg -l | grep aic8800
sudo dpkg -r aic8800d80fdrvpackage

2.17.2 执行驱动包清理脚本

cd ~/Downloads/麒麟系统_USB无线网卡驱动_V9/Linux/aic8800_linux_driver
chmod +x uninstall_setup.sh
sudo ./uninstall_setup.sh

这个脚本会删除：

/lib/firmware/aic8800D80/
/etc/udev/rules.d/aic.rules

2.17.3 清理后检查

lsmod | grep aic
find /lib/modules/$(uname -r) -name "*aic*.ko"
ls /lib/firmware | grep aic

2.18 本章结论

USB WiFi 网卡接入银河麒麟 V10，不是单纯插入设备就能使用。关键在于两件事：

先补齐编译环境和当前内核 headers
再运行驱动包提供的安装流程

驱动安装成功后，双网共存的关键是路由、DNS、代理三者一致：

路由：default 走 wlx688fc9592dbc，10.30.0.0/16 走 enaphyt4i0
DNS：内网域名走 10.30.255.1，其他域名走外部 DNS
代理：内网域名和内网 IP 必须 DIRECT，不经过远程代理

最终不能只用一个网页判断，而要分层验证：

ip route get 10.30.20.107
nslookup ips.sx.hsip.gov.cn 10.30.255.1
curl -s --connect-timeout 5 --noproxy '*' "https://www.baidu.com" -o /dev/null -w "%{http_code}\n"
curl -s --connect-timeout 5 --noproxy '*' "http://ips.sx.hsip.gov.cn/" -o /dev/null -w "%{http_code}\n"

只有路由、DNS、代理规则同时正确，内外网才能稳定共存。

第三章：银河麒麟 V10 软件安装、兼容性判断与代理软件案例

3.1 本章目标

银河麒麟 V10 上安装软件，不能简单照搬 Windows、macOS 或 Ubuntu 的习惯。

在常见个人电脑上，安装软件通常只需要考虑：

下载哪个安装包
双击能不能安装
软件界面能不能打开

但在银河麒麟 V10，尤其是 ARM64 架构的单位电脑上，下载软件前要先判断：

CPU 架构是否匹配
glibc 版本是否满足
系统库版本是否满足
桌面框架是否兼容
是否需要内核模块
是否依赖 Ubuntu 新版软件源

本章重点记录：

常用软件为什么会安装失败
下载前应该检查哪些信息
不同安装包应该怎么判断
代理软件为什么试了多个，最后只有 Mihomo Party 可用
以后遇到类似问题如何选择替代方案

3.2 银河麒麟 V10 的软件安装限制

这台单位电脑的几个关键限制如下：

限制项	当前情况	影响
CPU 架构	`aarch64 / ARM64`	不能安装 x86_64 软件
glibc	`2.31`	不能运行要求 glibc 2.34、2.35、2.38 的新软件
内核	`5.4.18-27-generic`	编译驱动必须匹配当前内核 headers
桌面环境	UKUI	部分图形程序显示、托盘、代理设置不完全一致
WebKitGTK	旧版本常见	Tauri v2 程序可能缺依赖
软件源	麒麟源	不应随意混入 Ubuntu、Kali、Debian 新版本源

其中最重要的是：

架构必须是 arm64 / aarch64
glibc 需求不能高于系统实际版本
系统依赖库不能强行从新系统混装

很多软件失败，不是因为“银河麒麟不能用 Linux 软件”，而是因为下载的包不适合这台机器。

3.3 和普通 Linux 软件安装最大的不同

普通 Ubuntu x86_64 电脑的软件生态非常丰富。很多项目默认只发：

amd64.deb
x86_64.AppImage
x86_64.tar.gz

但这台银河麒麟电脑是：

aarch64 / arm64

所以看到 Linux 安装包时，第一反应不能是下载，而是先看架构。

常见架构名称对应关系：

名称	含义	这台电脑是否可用
`amd64`	x86_64 PC	不可用
`x86_64`	x86_64 PC	不可用
`arm64`	64 位 ARM	可用
`aarch64`	64 位 ARM	可用
`armhf`	32 位 ARM	通常不可用

判断本机架构：

arch
uname -m

期望：

aarch64

3.4 下载软件前的通用检查清单

下载任何 Linux 软件前，建议先按下面顺序检查。

3.4.1 检查软件包架构

如果是 .deb：

dpkg-deb --info 软件包.deb | grep -E "Package|Version|Architecture|Depends"

重点看：

Architecture: arm64

如果是二进制文件：

file ./软件名

期望看到：

ARM aarch64

如果看到：

x86-64

就不能在这台电脑上直接运行。

3.4.2 检查 glibc 版本需求

查看系统 glibc：

ldd --version

查看二进制要求的 glibc：

objdump -T ./软件名 | grep -o 'GLIBC_[0-9.]*' | sort -Vu

如果软件要求：

GLIBC_2.34
GLIBC_2.35
GLIBC_2.38

而系统只有：

glibc 2.31

这个软件基本不能直接运行。

不要为了一个软件强行升级 glibc。glibc 是系统核心库，强行升级可能导致系统大量程序不可用。

3.4.3 检查动态库缺失

ldd ./软件名 | grep "not found"

如果有 not found，说明缺库。处理顺序是：

先查麒麟源有没有
再查软件官方是否提供完整包
最后才考虑源码编译或替代软件

不建议直接从 Ubuntu 22.04 或 24.04 下载依赖库混装。

3.4.4 检查 deb 依赖

dpkg-deb --info 软件包.deb

重点看：

Depends:

如果依赖里出现系统没有的新版库，例如：

libwebkit2gtk-4.1-0
libstdc++13
libicu74
libssl3
glibc >= 2.34

就要谨慎。银河麒麟 V10 可能没有这些包，或者版本明显更旧。

3.5 不同安装方式的优先级

在银河麒麟 V10 上，建议按下面顺序选择安装方式。

3.5.1 优先：麒麟软件源或软件商店

优点：

依赖兼容性最好
系统升级时可维护
不容易破坏系统

命令：

apt-cache search 软件名
apt-cache policy 软件包名
sudo apt install 软件包名

缺点是软件版本可能较旧，或者没有想要的软件。

3.5.2 第二选择：官方 arm64 deb 包

如果软件官方提供：

linux arm64 deb
aarch64 deb

可以优先尝试。

安装前先检查：

dpkg-deb --info 软件包.deb

安装：

sudo dpkg -i 软件包.deb
sudo apt --fix-broken install

3.5.3 第三选择：arm64 AppImage

AppImage 的优点是自带部分依赖，不需要安装到系统目录。

使用方式：

chmod +x 软件名.AppImage
./软件名.AppImage

但 AppImage 仍然可能失败：

架构不匹配
glibc 版本过高
需要 FUSE
需要系统图形库

如果提示 FUSE 问题，可以尝试：

./软件名.AppImage --appimage-extract

然后进入解包目录运行。但这只能解决部分 AppImage 挂载问题，不能解决 glibc 不兼容。

3.5.4 第四选择：Go / Java / Electron 类软件

在银河麒麟 V10 上，相对更容易成功的是：

Go 静态编译程序
Java 程序
Electron 程序
Qt5 程序

原因是它们对系统桌面库的依赖相对可控。

但 Electron 程序也不一定都能稳定运行，可能遇到：

GPU 渲染问题
沙箱问题
托盘问题
系统代理设置不兼容

常见启动参数：

软件名 --no-sandbox --disable-gpu

3.5.5 谨慎选择：Flutter / Tauri 新版本 GUI

这两类软件在新 Linux 发行版上体验不错，但在银河麒麟 V10 上容易踩坑。

Flutter Linux 程序常见问题：

编译环境较新
运行时要求 GLIBC_2.34+
旧系统无法直接运行

Tauri v2 程序常见问题：

依赖系统 WebKitGTK
可能要求 libwebkit2gtk-4.1-0
银河麒麟 V10 只有较旧 WebKitGTK
强行安装新 WebKit 会牵出大量新依赖

所以看到 Tauri / Flutter 软件时，必须先检查依赖。

3.6 不建议做的事情

3.6.1 不要随意添加 Ubuntu 新版源

例如不要为了装一个软件，直接添加：

Ubuntu 22.04
Ubuntu 24.04
Debian testing
Kali

这些源可能带来新版 glibc、libstdc++、openssl、webkit 等核心库，破坏系统兼容性。

3.6.2 不要强行升级 glibc

glibc 是系统最基础的运行库。强行升级会影响：

桌面环境
系统服务
包管理器
已安装业务软件
国产应用

一个普通应用要求新 glibc，正确思路不是升级系统 glibc，而是换适配旧 glibc 的版本或替代软件。

3.6.3 不要只看软件名，不看构建方式

同一个软件，不同构建方式兼容性完全不同。

例如代理客户端可能有：

Flutter 版本
Tauri 版本
Electron 版本
纯命令行核心版本

它们名字相似，但系统依赖完全不同。

3.7 代理软件安装案例

代理软件是这次最典型的软件兼容性案例。

尝试过多个软件后，最终本机实际可用方案是：

Mihomo Party + mihomo 核心

其他软件不是完全没有价值，而是在当前系统环境下存在不同限制。

3.7.1 mihomo 核心

mihomo 是 Clash Meta 后续使用较多的核心名称。它本身是代理核心，不是完整图形客户端。

优点：

Go 程序，依赖少
容易提供 arm64 版本
适合旧 glibc 系统
可以作为 systemd 服务运行

本机位置：

/usr/local/bin/mihomo

检查：

which mihomo
mihomo -v
systemctl status mihomo --no-pager

缺点：

命令行核心不适合普通用户直接维护
配置文件复杂
需要配合 GUI 或 Web 面板使用

3.7.2 Mihomo Party

本次最终可用的是 Mihomo Party。

本机位置：

/opt/clash-party/

检查进程：

ps -ef | grep -i "mihomo\\|clash-party" | grep -v grep

它能用的原因大致是：

内置或适配 mihomo 核心
图形界面比纯命令行友好
Electron 类程序相对更容易在旧系统上运行
可以接管系统代理

但它也带来了第二章提到的问题：

fake-ip 可能影响内网域名
DoH 可能绕过系统 DNS
use-hosts: false 会导致 /etc/hosts 不生效
规则不正确时，内网请求会被送到远程代理

所以 Mihomo Party 虽然是最终可用方案，但使用时必须配好：

DOMAIN-SUFFIX,sx.hsip.gov.cn,DIRECT
DOMAIN-SUFFIX,hsip.gov.cn,DIRECT
内网 DNS：10.30.255.1
内网网段：DIRECT

3.7.3 FlClash

FlClash 属于 Flutter GUI 客户端。

在银河麒麟 V10 上容易遇到的问题：

Flutter Linux 构建产物要求较新 glibc
系统 glibc 只有 2.31
可能启动时报 GLIBC_2.34 或更高版本缺失

判断方式：

file ./flclash
objdump -T ./flclash | grep -o 'GLIBC_[0-9.]*' | sort -Vu
ldd ./flclash | grep "not found"

如果看到软件要求的 glibc 高于系统版本，就不要继续折腾依赖库。更实际的处理是换客户端。

结论：

FlClash 在新 Linux 上可能很好用，但不适合作为这台银河麒麟 V10 的首选方案。

3.7.4 Koala Clash

Koala Clash 是 Electron 类 GUI 客户端。

Electron 的优势是自带 Chromium，对系统 WebKit 依赖较少。因此理论上比 Tauri / Flutter 更容易适配旧系统。

但在本机实际使用时，它不是最终稳定方案。可能遇到的问题包括：

显示或 GPU 渲染问题
沙箱问题
系统代理接管不一致
与已有 mihomo 服务端口冲突
和当前订阅、规则、内网绕过配置不完全匹配

如果要测试 Electron 类客户端，可以尝试：

软件名 --no-sandbox --disable-gpu

如果端口冲突，检查：

ss -lntup | grep -E "7890|9090"
systemctl status mihomo --no-pager

结论：

Koala Clash 可以作为备选测试，但本次最终稳定使用的是 Mihomo Party。

3.7.5 Clash Verge Rev

Clash Verge Rev 新版本常见为 Tauri GUI。

在银河麒麟 V10 上容易遇到：

依赖 libwebkit2gtk-4.1-0
系统只有较旧 WebKitGTK
强行安装新版 WebKit 会牵出 glibc、libstdc++、libicu 等依赖

这种问题不建议通过混装 Ubuntu 新包解决。

结论：

Tauri v2 客户端在银河麒麟 V10 上风险较高。

3.8 代理软件选择原则

以后再选代理软件，可以按这个顺序判断：

1. 是否有 arm64 / aarch64 版本
2. 是否要求 glibc 高于 2.31
3. 是否依赖系统 WebKitGTK 4.1 或更高
4. 是否支持系统代理和绕过规则
5. 是否能对内网域名设置 DIRECT
6. 是否能指定内网 DNS

推荐优先级：

优先级	类型	原因
高	mihomo 核心 + 可用 GUI	核心稳定，规则能力强
高	Electron GUI	对系统 WebKit 依赖较少
中	Go / Qt 客户端	依赖相对可控
低	Flutter GUI	可能要求新 glibc
低	Tauri v2 GUI	可能要求新 WebKitGTK

3.9 安装代理软件后的检查清单

3.9.1 检查程序是否启动

ps -ef | grep -i "mihomo\\|clash\\|party" | grep -v grep

3.9.2 检查端口

ss -lntup | grep -E "7890|9090"

常见端口：

7890：mixed-port / HTTP / SOCKS
9090：控制面板 API

3.9.3 检查系统代理

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy ignore-hosts

3.9.4 检查内网是否被代理

curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/" 2>&1 | head -40
curl -v --connect-timeout 10 "http://ips.sx.hsip.gov.cn/" 2>&1 | head -40

如果第一条成功、第二条失败，说明系统代理或代理规则仍在影响内网访问。

3.10 常用软件安装判断模板

以后遇到一个新软件，可以按下面模板做判断。

第一步：确认系统

uname -m
ldd --version
uname -r

第二步：确认安装包

file 软件名
dpkg-deb --info 软件名.deb 2>/dev/null

第三步：确认依赖

ldd 软件名 | grep "not found"
objdump -T 软件名 | grep -o 'GLIBC_[0-9.]*' | sort -Vu

第四步：小范围测试

不要直接替换系统配置。先在当前目录运行：

./软件名 --version
./软件名

如果是 GUI 软件，优先从终端启动，方便看到报错。

第五步：再决定是否安装到系统

如果确认可运行，再考虑：

是否安装 deb
是否创建桌面快捷方式
是否设置开机启动
是否接管系统代理
是否写入 systemd 服务

3.11 遇到软件不兼容时的解决方案

方案一：找旧版本

如果新版本要求高 glibc，可以找旧版本。

查找方向：

GitHub Releases 历史版本
软件官网旧版下载
发行版适配版
厂商提供的 arm64 包

方案二：换构建类型

同一个软件可能有不同客户端：

Flutter 不行，试 Electron
Tauri 不行，试 Qt
GUI 不行，试命令行核心 + Web 面板
AppImage 不行，试 deb
deb 不行，试 tar.gz

方案三：使用核心程序代替 GUI

例如代理软件可以用：

mihomo 核心 + Mihomo Party
mihomo 核心 + Web UI

而不是强行安装某个不兼容的 GUI 客户端。

方案四：源码编译

源码编译适合：

Go 项目
部分 C/C++ 工具
不依赖复杂桌面框架的软件

不适合：

大型 GUI
依赖大量新系统库的软件
需要新版 Rust / Node / Flutter 工具链的软件

方案五：远程或 Web 替代

如果本机 GUI 客户端无法运行，可以考虑：

浏览器访问 Web 版
内网部署服务端
使用远程桌面
命令行工具 + Web 控制台

3.12 本章结论

银河麒麟 V10 安装软件，核心不是“这个软件有没有 Linux 版”，而是：

有没有 arm64 版
glibc 是否兼容
系统依赖是否能满足
桌面框架是否适合旧系统
是否会破坏现有网络和代理配置

代理软件案例说明了这一点：

FlClash 可能卡在 Flutter / glibc
Clash Verge Rev 可能卡在 Tauri / WebKitGTK
Koala Clash 可作为备选但本机不是最终稳定方案
Mihomo Party + mihomo 是本次最终可用方案

以后遇到软件安装问题，不要先急着找“万能安装命令”，而要先判断：

架构
glibc
依赖
安装包类型
是否有替代客户端
是否会影响内外网共存

这套判断流程，比单纯反复下载不同安装包更可靠。