代理节点访问纯 IP 地址报错的排查与解决

一名话就是很多机场限制http协义的非标准端口访问.

1. 问题现象

在使用代理软件（如 honk / dae / clash 等）接管系统流量后，尝试通过浏览器访问一个纯 IP 加上非标准端口的 HTTPS 地址（例如 https://192.0.2.1:38220）。

• 浏览器报错：Firefox 提示 PR_END_OF_FILE_ERROR（建立安全连接失败）。
• 对照测试：将流量切换到“自建代理节点”后，该链接可以正常打开并建立 HTTPS 连接。

2. 问题排查与分析

PR_END_OF_FILE_ERROR 错误表示本地客户端与远端代理服务器虽然成功建立了底层的 TCP 连接，但在准备进行 HTTPS 加密握手（发送 ClientHello）的瞬间，连接被远端的代理服务器单方面强行切断了。

由于自建节点可以正常访问，说明本地的路由分流规则正常，且目标服务器并没有限制访问。问题核心在于商业机场节点（代理服务端）的限制策略。常见原因如下：

1. 机场审计规则拦截（最常见）：为了防止用户利用代理节点进行全网端口扫描、BT 下载或网络攻击，大多数商业机场会在服务端配置严格的防火墙（ACL）。直接请求纯 IP 且携带极高的非标准端口，极容易触发机场的“恶意行为风控”，导致服务端瞬间丢弃该连接。
2. 缺乏 SNI 导致服务端无法处理：商业机场的后端架构（如 Nginx Stream 或 HAProxy）通常依赖请求中的域名（SNI – Server Name Indication）来进行流量的负载均衡和路由分发。纯 IP 请求不包含 SNI，服务端无法识别流量去向，只能强制断开。

3. 解决方案

遇到此类服务端限制，最直接有效的办法是利用客户端的路由规则进行精准分流，避开限制严格的商业节点。

方案：将特定 IP 路由至自建节点或直连

如果你有自建节点（通常没有严格的审计限制），可以修改代理软件的路由规则。

以 dae / honk 语法为例：

修改前（流量默认走商业机场组 Proxy，导致被拦截）：

routing {
    # ...其他规则...
    dip(192.0.2.1) -> Proxy 
}

修改后（将该纯 IP 强行指向包含自建节点的策略组 Self-Node）：

routing {
    # ...其他规则...
    dip(192.0.2.1) -> Self-Node 
}

修改完成后，重载或重启代理核心（如 systemctl restart honk-core），刷新浏览器即可正常建立安全连接。