连接信息与协议

本页介绍节点服务器“入口”与“出口”之间的连接行为，转发协议，以及软件的一些“高级配置”。

如何知道其他服务器的 IP

默认情况下，节点端都会上报自己的「公网 IP」地址。

如果您没有指定设置，那么出口服务器将随机监听端口，上报「公网 IP + 监听端口」至面板服务器，此信息后续被入口服务器拉取，入口服务器就可以连接到出口服务器。

如果需要改变这个行为，请看「出口设置」。

设备组 config

设备组 config 为 JSON 格式。

部分设置项可以通过 编辑 修改，如果需要查看或编辑所有设置项，请使用 高级编辑 功能。

提示，编写配置时请带上脑子

面板中的 JSON 编辑不支持注释，请自行删去注释。
请按自己的需求填写，不懂的参数不要填。不要照抄示例，示例中的值不一定是默认值。

入口设置

入口设置位于入口设备组的 config 中，以 JSON 格式保存。

前端界面会读取入口设备组中的 config 以展示入站屏蔽了哪些协议和域名。

{
    // 屏蔽选项
    "allowed_host": [], // 白名单的 Host / SNI，与其他屏蔽选项冲突
    "blocked_host": [], // 黑名单的 Host / SNI
    "blocked_path": [], // 黑名单的 HTTP Path
    "blocked_protocol": [], // 黑名单协议，可取值看下方说明
    // 隧道选项
    "udp_over_tcp": false,
    "disable_udp": false,
    "ipv6_group": [],
    // 故障转移：指定 入口连接隧道出口 或者 入口直出 时的故障转移策略。
    "max_fail": 3, // 开始转移前，容忍的最大连续失败次数
    "fail_timout_sec": 30 // 转移的时长（秒）
}

需要注意

disable_mux direct protocol 等选项强烈建议不要乱改设置，请保持默认。因为这些选项设置的不好会导致被墙、无法连通或性能爆炸。

ipv6_group

指定哪些出口设备组需要优先走 IPv6，填写设备组整数 ID，如 [3, 4, 5]。

特殊写法：

[0] 表示所有出口都优先使用 IPv6。
[0, 1, 2] 表示所有出口都优先使用 IPv6，但 1 和 2 优先使用 IPv4。

各种连接地址的优先度

从上到下尝试，取第一个符合条件的地址。

connect_type == "static" && connect_address != ""
connect_host != ""
dyn_ip4
ipv6_group
dyn_ip6
最后兜底使用公网 IPv4 地址

注意：连接地址没有回落机制

如果您使用 IPv6 连接对端，请确保入口机器有可用的 IPv6 网络。除非某个对端没有公网 IPv6 地址，其他情况即使连接失败，也不会使用 IPv4。

blocked_protocol

socks
fet 屏蔽全加密（ss/vmess）协议
http
tls

group.json

如果本地工作目录存在 group.json ，则会覆盖远程的入口设置。

某些 config 的变更可能需要重启节点端才能生效。

出口设置

出口设置位于出口设备组的 config 中，以 JSON 格式保存。

属于“连接信息”的配置项一般用于控制“入口服务器连接本组出口”时的行为。

{
    // 连接信息
    "connect_type": "static", // 可选： dyn_ip4 / dyn_ip6 / static
    "connect_address": "node.example.com", // static 专属
    "connect_port": 2333, // static 专属
    "protocol": "ws",
    "ws": {
        // ws object
    },
    "udp_over_tcp": false
}

connect_type: 如果不指定，默认使用 ipv4 或者每个对端的 connect_host 连接。

dyn_ip4: 强制指定使用公网 ipv4 连接。

dyn_ip6: 强制指定使用公网 ipv6 连接，如果入口或出口不支持 v6 也不会自动回退到 v4。

static: 强制指定使用出口配置中的 connect_address connect_port 连接，目前只能指定一个地址，不建议使用域名。

规则设置

规则设置位于「转发规则」中，以 JSON 格式保存。

部分设置项可以通过 编辑 修改，如果需要查看或编辑所有设置项，请使用 高级编辑 功能。

{
  // TLS 入站设置
  "tls": {
    // empty_sni 和 sni 二选一，请根据自己情况设置。
    "empty_sni": false, // 不校验客户端发送的 SNI。默认: false
    "force_empty_sni": false, // 开启 empty_sni 的同时，拒绝带有 SNI 的请求。默认: false
    "sni": "i0.hdslb.com", // 仅限带有此 SNI 的客户端连接到服务器。nc20250930 版本起，可填多个，用逗号分割。
    // ALPN 如果不为空，则校验客户端发送的 ALPN。
    "alpn": [
      "http/1.1"
    ]
  }
}

TLS 入站

入口监听 TLS，为入站连接加载 TLS 层。TLS 握手将在入口服务器完成，然后 TLS 内层流量将通过隧道传输至后续服务器。

此功能与 blocked_protocol 等不冲突，若入口禁止了 TLS，则无法成功握手。

目前只支持自签名证书，请为客户端设置好 allow-insecure sni 等参数。

如需更多复杂功能请自行在入口运行 nginx 等专业软件。

TCP 隧道协议

nyanpass 的隧道协议是自主设计的基于 TCP 的协议，为符合互联网多数流量特征，目前仅允许采用 ws http tls 方式传输。

隧道协议自带连接复用，实现多数请求 0-RTT，不增加任何延迟（包括 TCP 握手的延迟）。

所有基于 TCP 的协议在第一次建立连接时均会耗费 1RTT，若有 TLS 层再多 1RTT。由于默认开启了复用层，这种延迟只会在少数的实际连接中出现。

针对需要过墙的用户的提醒：

http/ws 协议非常假，如果没有特殊需求，请优先使用 tls 协议。
目前（2025 年 9 月） http/tls 隧道协议不会像 SS/Vmess/Trojan/Vless 那样自动被 GFW 墙，ws 协议可能会触发 GFW 的某种并发限制导致断流。
目前所有协议可能都无法逃过某种含有人工因素的 IP 筛查与封禁。但是这种情况的出现频率较低，例如 2025 年 1~9 月只出现了约 4 批次的封禁行动，并且有集中行动的特征。
如果你觉得还是不保险，可以尝试开启 chfp 伪装 TLS ClientHello 指纹，且/或填写合适的 sni，但是这个方法的效果还没有充分测试过。

以上内容只对国外跳板 IP 有效。

对于国内 IP，可以参考「反向墙」页面的部分描述。由于人工因素占比更高（打击的是境内翻墙行为，所以用什么方式过墙都无济于事），处理方法更抽象（例如封海外、通报拔线），资源更稀缺，规避更难，目前无法给出有效建议。

ws

版本：自 nc20250613 起由 ws ws2 统一合并为 ws。

特点：非完整 ws 协议，性能优秀，无额外延迟，传输内容自带简易加密。

出口设备组 ws config:

{
    "ws": {
        "host": "some.host.com",
        "path": "/some/path",
        // request & response
        // 可以设置完整的 http 头，不一定需要正确，只要 HTTP 库能读出来就可以了（能连就行）。
        // 这与大部分 HTTP 中间件不兼容。如果您设置了这些选项，隧道两端请务必直接 TCP 连接。
        // 如果设置不当，可能导致被墙或者卡死。
        "request": "GET / HTTP/1.5\r\n\r\n",
        "response": "HTTP/1.5 200 OK\r\n\r\n"
    }
}

http

版本：nc20250613 起可用。

特点：继承了 ws 大部分要素的 FakeHTTP 协议。请求/响应头中不包含 upgrade switch protocol 等信息，以规避某些网络对 ws 的限制。

同样可以用 ws config 调整 host 和 path。

tls_simple

版本：早期的 realm tls 协议在 nc20240329 版本起已经合并到 tls_simple 协议。

特点：使用 Go TLS 承载 Nyanpass 协议，性能优秀。

出口设备组 tls config:

{
  "tls": {
    "sni": "some.host.com",
    "alpn": [
      "http/1.1"
    ],
    "chfp": "chrome"
  }
}

chfp: 利用 utls 伪装 ClientHello 的指纹，默认不开启。（nc20250930 版本起）

目前可以填以下指纹。如果 chfp 的值不在以下列表，则不进行指纹伪装。

chrome
firefox
safari
ios
android
edge
360
qq

UDP 转发协议

无论 protocol 为何，只要不开启 udp_over_tcp，转发处理 udp 时始终使用基于原生 udp 的转发协议，保证 udp 的特性不丢失。

此协议的 MTU 开销为 28 字节，转发内容有简易加密。

如果开启 udp_over_tcp，则 udp 数据将通过 tcp 流承载，通过隧道协议传输。

不推荐使用本软件转发 UDP。我们只提供“能用”的 UDP 转发，并无对 UDP 的优化。

入口直出

适合专线使用。非隧道（意味着不能过墙），无需出口机器。转发开销极小，非常稳定。

有些人会把这种转发叫做直接转发或者 TCP+UDP 转发，是同一种东西。