DEV Community: amoorzheyu

修改 SSH 默认端口导致密钥登录失败的排查与解决

amoorzheyu — Sun, 25 Jan 2026 10:46:02 +0000

最近在服务器上修改了 SSH 默认端口，遇到密钥登录卡住、超时的问题。这里记录一下排查和解决过程，方便以后参考。

前提条件确认

在排查前，我确保了以下条件：

服务器本地防火墙已经关闭或允许新端口
云服务商安全组/防火墙已经放行该端口
TCP 连接能够正常建立（通过 telnet IP 端口号 验证）

也就是说网络通畅，问题出在 SSH 配置或认证阶段。

问题现象

修改端口后，使用密钥登录时客户端出现超时，日志大致是：

Outbound: Sending SERVICE_REQUEST (ssh-userauth)
Inbound: Received EXT_INFO
Timed out while waiting for handshake

分析发现：

TCP 连接正常
SSH 握手完成
卡在密钥认证阶段，服务端不响应

排查分析

PubkeyAuthentication 默认被禁用

查看 /etc/ssh/sshd_config：

   #PubkeyAuthentication yes

注释掉意味着密钥登录默认关闭
客户端发送密钥请求时服务端不响应 → 超时

结论：修改默认端口后，很多 Linux 镜像会默认将密钥登录注释掉。

SSH 对权限非常严格，如果不正确也会导致认证失败：

   /home/user        755
   /home/user/.ssh   700
   authorized_keys   600

SELinux 或云安全组件

SELinux 可能阻止 SSH 读取公钥
云厂商安全组件可能限制非默认端口的密钥登录

前提是网络通畅、防火墙放行的情况下，这些仍可能导致问题。

解决过程

显式开启密钥认证

修改 /etc/ssh/sshd_config：

   PermitRootLogin yes
   PubkeyAuthentication yes
   AuthorizedKeysFile .ssh/authorized_keys
   PermitEmptyPasswords no
   Subsystem       sftp    /usr/libexec/openssh/sftp-server

检查权限

   ls -ld /home/user
   ls -ld /home/user/.ssh
   ls -l /home/user/.ssh/authorized_keys

/home/user → 755
.ssh → 700
authorized_keys → 600

重启 SSH 服务

   sudo systemctl restart sshd

本地测试密钥登录

   ssh -i /path/to/private_key -p 端口号 user@服务器公网IP

登录成功后问题解决。

总结

修改 SSH 默认端口后，密钥登录可能会默认被禁用。
即便关闭了防火墙和云供应商安全组，也可能出现问题，因为 SSH 默认策略或安全组件会阻止密钥认证。
核心解决办法：显式开启 PubkeyAuthentication yes，保证家目录和 .ssh 权限正确。

系统代理配置不可持久化的问题排查与解决

amoorzheyu — Sun, 25 Jan 2026 07:41:32 +0000

最近在使用 Mihomo（Clash 内核） 时，我遇到了一个非常具体、但又绕不开的实际问题：
我需要在开启系统代理的同时，正常访问公司内网的域名，而系统代理这一层恰好出了问题，并且在这个软件里无法配置。

这篇文章记录的不是网络原理本身，而是系统代理配置在现实使用场景中被覆盖、无法持久化时，应该如何工程化地解决，以及最终我为什么选择用一个 bat 脚本来兜底。

一、真实的使用场景：系统代理 + 内网域名访问

先说清楚背景动机。

我的使用场景是：

浏览器需要使用系统代理（由 Mihomo 提供）
同时需要访问公司内网网站
内网网站是通过 内网域名 访问的
这些域名依赖：
- 系统路由
- 内网 DNS
不能走代理

在 Windows 下，浏览器是否走代理，完全由 系统代理配置 决定，尤其是：

“不使用代理的地址”（ProxyOverride）

只要内网域名没有被正确配置在这里：

浏览器请求就会被交给代理程序
解析和连接都会走错路径
结果就是内网网站无法访问

二、问题出现：系统代理例外配置无法保持

一开始的操作非常直觉：

打开 Windows 系统代理设置
在“不使用代理的地址”里添加：
- 内网网段
- 内网域名
保存

当下效果是完全正确的：

内网域名立刻可以访问
行为符合预期

但问题在于：

关闭 Mihomo
再重新启动
刚刚添加的系统代理例外全部消失

而且这是一个稳定可复现的现象。

这说明问题已经不在“配置是否正确”，而在于：

有程序在启动时主动覆盖了系统代理配置。

三、确认事实：Mihomo 启动会重写系统代理

通过简单的验证可以确认：

在 Mihomo 未运行时修改系统代理
注册表中 ProxyOverride 已正确更新
启动 Mihomo
对应配置被整体重写

这意味着：

Mihomo 在启动时
并不是“读取并合并”现有系统代理配置
而是直接写入一套固定模板

这也是为什么：

手动改 UI 没有持久性
重启软件就会丢失配置

四、为什么这个问题在 Mihomo 里无法解决

接下来一个很自然的想法是：
能不能在 Mihomo 里直接配置这些系统代理例外？

结论是：不能。

原因在于设计取向：

Mihomo 关注的是：
- 代理端口
- 规则匹配
- 代理侧 DNS
Windows 系统代理对它来说只是：
- 一个“启动时顺手写一次”的配置

系统代理例外（ProxyOverride）并不是它希望用户长期维护的配置项。

换句话说：

系统代理配置只是 Mihomo 的副作用，而不是它的核心能力。

五、关键认知转变：UI 不是最终真相

到这里，一个关键认知就很清楚了：

Windows 的系统代理设置页面只是一个 UI
真正决定行为的是注册表

所有系统代理相关内容最终都落在：

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

其中关键字段是：

ProxyOverride

在这个模型下：

谁最后写入，谁就拥有最终控制权。

而在我的场景中：

Mihomo 每次启动都会成为“最后写入者”

六、思路转变：不阻止覆盖，而是在覆盖后修正

确认这些事实之后，解决思路反而变简单了：

不试图阻止 Mihomo 写系统代理
不反复通过 UI 去“抢配置”
而是：

接受覆盖的存在，在覆盖完成之后，把配置修正回来。

这是一个典型的工程问题，而不是配置技巧问题。

七、最终方案：用 bat 脚本维护 ProxyOverride

系统代理例外本质上只是一个字符串：

分号分隔
支持通配符
支持内网域名
支持 <local>

非常适合脚本化维护。

脚本的目标只有一个：

无论当前系统代理被写成什么样，都把 ProxyOverride 改成我期望的状态。

使用方式

启动 Mihomo
执行一次脚本
系统代理例外立即恢复

八、最终使用的 bat 脚本

下面是我最终使用的脚本内容，逻辑尽量保持简单和稳定。

@echo off

REM =========================
REM ProxyOverride 脚本
REM =========================

set LOCAL_BASIC=localhost;127.*
set PRIVATE_NETS=10.*;192.168.*
set PRIVATE_172=172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;172.26.*;172.27.*;172.28.*;172.29.*;172.30.*;172.31.*

REM 注意：<local> 不能进 set 变量
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyOverride /t REG_SZ /d "%LOCAL_BASIC%;%PRIVATE_NETS%;%PRIVATE_172%;*.suanleme.local;<local>" /f

ie4uinit.exe -show

echo.
echo Current ProxyOverride:
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyOverride
echo.

这个脚本的特点是：

不依赖 UI
不依赖 Mihomo 是否支持配置
每次执行结果确定
可随时修改、扩展内网规则

九、最终效果

使用脚本后，流程变成：

启动 Mihomo
系统代理被写入其默认配置
执行脚本
内网域名被正确排除出系统代理

结果是：

内网网站访问稳定
不再反复检查系统代理 UI
不再担心“下次启动又坏了”

十、总结

这次问题表面上是：

“系统代理配置为什么保存不了？”

但真正学到的是：

当配置反复被覆盖时，说明你找错了修改入口
UI 只是表象，注册表才是底层事实
当工具不支持你的需求粒度时：
- 与其反复手工操作
- 不如用脚本补齐能力

最终我接受了一个很工程化的结论：

当配置开始变得不可控时，
脚本不是折腾，而是最稳妥的解决方案。

把这次过程记录下来，避免以后再从同一个坑重新踩一遍。

双 VPN 环境下的一次排错记录：内网域名无法访问的问题

amoorzheyu — Sun, 25 Jan 2026 06:34:49 +0000

最近在使用双 VPN 的网络环境时，遇到了一次比较典型但又容易被忽略的问题：一边需要翻墙访问公网，一边又要连接公司内网，结果发现内网网站通过域名无法访问。这里记录一下整个排查和解决过程，作为一篇个人使用日志。

背景

当时的网络环境是同时开启了两个 VPN：

VPN A：Mihomo Party

用于翻墙访问墙外网站
采用规则模式，规则中已经排除了内网域名

VPN B：OpenVPN

用于访问公司内网
内网中包含数据库、内部网站以及其他服务

从设计上看，两个 VPN 的职责是明确分开的：
公网流量交给 Mihomo，内网流量交给 OpenVPN。

问题现象

问题出现时的表现比较奇怪：

公网网站可以正常访问，翻墙没有问题
内网数据库可以正常连接
但通过浏览器访问内网网站（使用域名）却始终打不开

这说明问题并不是简单的“内网不通”。

初步排查

首先检查的是最基础的连通性。

使用 ping 测试内网域名，结果是正常的，这意味着：

OpenVPN 隧道是通的
内网路由没有问题

既然网络层没问题，那就只能把注意力放到应用层。

逐步定位问题

接下来我把关注点放在浏览器和代理行为上。

浏览器默认是依赖系统代理的，而 Mihomo Party 启动后会接管系统代理设置。虽然在 Mihomo 的规则中已经把内网域名设置为 DIRECT，但浏览器的请求实际上仍然会先被送到 Mihomo。

这一步本身并不一定有问题，真正的关键在于 DNS。

DNS 解析路径的差异

在这个双 VPN 场景下，实际上存在两套完全不同的 DNS 解析路径。

当流量走代理时：

浏览器
→ Mihomo Party
→ Mihomo 内置 DNS 或公网 DNS

这种情况下，内网域名是无法被正确解析的。

而当流量真正直连时：

浏览器
→ 系统路由
→ OpenVPN 下发的内网 DNS

只有走这条路径，内网域名才能解析成功，内网网站才能访问。

问题就出在这里：浏览器访问内网网站时，并没有真正绕过系统代理。

问题根因

总结下来，根因其实很清晰：

浏览器访问内网域名时，流量仍然被系统代理交给了 Mihomo，导致 DNS 使用的是公网侧的解析器，而不是 OpenVPN 提供的内网 DNS，从而造成内网域名解析失败。

解决办法

解决思路其实很直接：
让浏览器在访问内网资源时，彻底绕过系统代理。

在 Windows 系统中，这需要通过配置 系统代理的例外规则（ProxyOverride） 来实现。

具体操作如下：

打开 Internet 选项
进入 连接 → 局域网设置
在 代理服务器 中点击高级
在“不使用代理服务器的地址”中添加内网地址和域名，例如：

localhost;127.*;192.168.*;10.*;
172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;
*.suanleme.local

完成以上配置后，浏览器在访问这些地址时将：

不再经过代理程序
直接使用系统路由和内网 DNS
内网网站可以正常访问

但在实际使用中很快发现，这种方式只能暂时生效。
只要重新启动 Mihomo，系统代理的例外配置就会被覆盖，无法持久化。

针对系统代理配置不可持久化的问题，后续对原因进行了进一步排查，并最终通过脚本的方式进行修正，完整的分析和解决过程已整理如下：

系统代理配置不可持久化的问题排查与解决

再看一次整体流程

调整完成后，整个访问逻辑就变得很清晰了。

内网域名
- 浏览器直连
- 使用 OpenVPN 下发的内网 DNS
- 可以正常访问
公网域名
- 浏览器走系统代理
- 由 Mihomo Party 转发
- 使用 Mihomo 内置 DNS 翻墙访问

内网和公网各走各的路，互不干扰。

结果验证

修改系统代理例外后：

浏览器可以正常访问内网网站
公网网站依然可以正常翻墙
内网数据库访问没有受到任何影响

双 VPN 可以稳定同时使用。

小结

这次问题的关键不在 VPN 本身，而在于浏览器、系统代理和 DNS 之间的配合关系。

在双 VPN 环境下：

分流规则只是第一步
系统代理例外决定浏览器是否真正直连
DNS 解析路径最终决定访问是否成功

把这几个点想清楚之后，这类问题基本都能快速定位和解决。