内网穿透
什么时候需要这页
如果你没有公网 IP，但仍希望从外部访问内网中的 fknock 入口，通常就需要内网穿透。
文档主要覆盖两种方式：
FRPCloudflared
它们的共同点只有一个：
最终都要把外部流量送到本机的
7999。
使用内网穿透前的共同前提
无论你选哪一种，都建议先完成：
- 已切换到
反代模式 - 已配置 TOTP
- 已规划好映射
- 已经明确
7999是统一入口
如果这四件事还没理顺，先回看：
还要注意一点：
- 当前管理后台只会在
反代模式下显示内网穿透页面 - 如果你已经切到
直连模式或子域模式，相关页签会被隐藏
FRP 和 Cloudflared 怎么选
| 方案 | 更适合谁 | 核心特点 |
|---|---|---|
FRP | 自己有公网服务器，想完全控制端口的用户 | 传统 TCP 转发思路，外部通常通过服务端地址 + 远端端口访问 |
Cloudflared | 已在使用 Cloudflare，不想维护公网服务器的用户 | 通过 Cloudflare Tunnel 暴露域名，更偏 SaaS 接入体验 |
FRP 的典型思路
FRP 场景下，fknock 的角色通常是：
- 本地统一入口：
127.0.0.1:7999 - FRP 客户端把这个入口映射到 FRP 服务端某个远端端口
FRP 配置里默认会生成：
localIP = "127.0.0.1"localPort = 7999type = "tcp"transport.proxyProtocolVersion = "v2"
这意味着：
- 按默认思路填写即可
- 不需要再额外包一层本地 Web 代理
FRP 页面现在有两种编辑方式
内网穿透 → FRP 不再只有基础表单。
现在你可以在同一页里使用：
表单模式- 点击
自定义后进入源码模式
表单模式适合什么时候
适合：
- 只需要填写常规连接参数
- 主要维护
serverAddr、serverPort、token - 主要维护本地端口和远端端口
还要注意一个新行为：
- 表单模式只会覆盖当前已支持的字段
- 其他已经写在
frpc.toml里的 TOML 配置会继续保留，不会被清空
这意味着如果你后来补过一些额外参数，通常仍然可以继续先用表单维护常规字段。
源码模式适合什么时候
如果你已经有现成的 frpc.toml，或者准备补充表单还没覆盖到的参数，可以点击：
自定义
进入源码模式直接编辑 frpc.toml 原文。
- 保存前会先执行一次
frpc verify - 如果配置语法有问题，保存会直接报错
- 如果当前 TOML 还存在语法问题，也无法顺利切回
表单模式
所以更稳妥的顺序通常是：
- 先在
系统设置 → FRP准备好 FRP 资源 - 再进入
内网穿透 → FRP - 常规参数优先用表单维护
- 只有在需要补自定义项时，再切到源码模式
Cloudflared 的典型思路
Cloudflared 场景下，fknock 的角色通常是：
- 本地统一入口：
7999 - Cloudflare Tunnel 负责把公网域名请求带到本机
后台只需要保存：
Tunnel Token
真正的公网域名与回源协议，是在 Cloudflare Dashboard 里配置的。
这也是为什么我们专门拆出一页：
资源初始化在什么地方做
两种方案都需要先在系统设置里准备运行资源：
系统设置 → FRP系统设置 → Cloudflared
这一步的作用只是：
- 下载可执行文件或运行资源
并不等于已经开始穿透。
运行状态与日志怎么用
FRP 和 Cloudflared 页面都提供：
- 启动 / 停止
- 当前状态
- 运行日志
推荐的观察顺序：
- 先保存配置
- 再启动
- 看运行状态是否变成运行中
- 再看日志
- 最后才去外部网络测试
切换到直连模式前要注意什么
当你准备切回直连模式时，系统会优先尝试停止当前正在运行的 FRP 或 Cloudflared。
这也是一种明确提示：
内网穿透和直连模式不是同一套访问模型。