Update nexus: fix conflicts and sync local changes
This commit is contained in:
@@ -1,58 +1,58 @@
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:通过 VPS(公网服务器)+ frp(反向隧道)+ Caddy(自动 HTTPS 反向代理)实现家庭内网服务的公网域名访问
|
||||
- 问题域:家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务(如 n8n、Grafana、Transmission 等)如何通过自定义域名从公网安全访问
|
||||
- 方法/机制:Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps(frp 服务端)和 Caddy → 内网主机运行 frpc(frp 客户端)将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口,自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值:完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程,并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- frp 内网穿透工具包含 frps(服务端)和 frpc(客户端),通过 TCP 反向隧道将内网端口暴露到公网 VPS
|
||||
- Caddy 自动管理 HTTPS 证书(Let's Encrypt),无需手动配置 SSL,通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP,不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS,不经过 Caddy,仅通过 frps + frpc 的 TCP 映射实现
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接,需要停止代理后重启 frpc
|
||||
|
||||
## Key Quotes
|
||||
> "思路:Cloudflare DNS 指向 公网上的一台VPS,VPS 上运行 Caddy;内网主机通过 frp 将服务暴露到 VPS(本地 127.0.0.1 或某个端口),VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书,提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒(安全性)**:SSH 穿透与 HTTP 不同,它是纯 TCP 流量,不经 Caddy(Caddy 只处理 HTTP/HTTPS),所以:Caddy 不参与 SSH 的代理,只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]:通过公网服务器中转,使 NAT/防火墙后的内网服务可被外部访问的技术,本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]:Caddy 作为反向代理,将公网 HTTPS 请求转发到本地 frp 映射端口,提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]:frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道,支持非 HTTP 协议(如 SSH、MySQL)
|
||||
- [[自动HTTPS]]:Caddy 内置 Let's Encrypt 证书自动申请和续期,无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]:Cloudflare DNS 配置,将子域名(如 nas.ishenwei.online)指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]:VPS 提供商(192.227.222.142),托管 frps 服务端和 Caddy 反向代理,作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]:内网 NAS 设备(192.168.3.17),运行 frpc 客户端,通过 frp 暴露 NAS 服务(5000端口 → VPS 15000)
|
||||
- [[frp]]:开源内网穿透工具,本方案的核心,包含 frps(服务端,监听 7000 端口)和 frpc(客户端),版本 0.65.0
|
||||
- [[Caddy]]:Go 语言编写的自动 HTTPS 反向代理服务器,与 frp 配合为内网服务提供 HTTPS 域名访问
|
||||
- [[Cloudflare]]:域名 DNS 托管服务商,通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](本文是该概览中内网穿透架构的详细展开)
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](FRP 安装是该方案的前置步骤)
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](Mac Mini FRP 客户端配置参考)
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](Ubuntu Server 24.04 是本方案的目标操作系统)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点:
|
||||
- 冲突点:监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点:本文提供完整公网域名访问方案,包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点:监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置,未展开公网访问细节
|
||||
- 建议:在监控方案中补充指向本文内网穿透配置的外链,实现监控方案 + 公网访问的完整闭环
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:通过 VPS(公网服务器)+ frp(反向隧道)+ Caddy(自动 HTTPS 反向代理)实现家庭内网服务的公网域名访问
|
||||
- 问题域:家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务(如 n8n、Grafana、Transmission 等)如何通过自定义域名从公网安全访问
|
||||
- 方法/机制:Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps(frp 服务端)和 Caddy → 内网主机运行 frpc(frp 客户端)将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口,自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值:完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程,并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- frp 内网穿透工具包含 frps(服务端)和 frpc(客户端),通过 TCP 反向隧道将内网端口暴露到公网 VPS
|
||||
- Caddy 自动管理 HTTPS 证书(Let's Encrypt),无需手动配置 SSL,通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP,不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS,不经过 Caddy,仅通过 frps + frpc 的 TCP 映射实现
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接,需要停止代理后重启 frpc
|
||||
|
||||
## Key Quotes
|
||||
> "思路:Cloudflare DNS 指向 公网上的一台VPS,VPS 上运行 Caddy;内网主机通过 frp 将服务暴露到 VPS(本地 127.0.0.1 或某个端口),VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书,提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒(安全性)**:SSH 穿透与 HTTP 不同,它是纯 TCP 流量,不经 Caddy(Caddy 只处理 HTTP/HTTPS),所以:Caddy 不参与 SSH 的代理,只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]:通过公网服务器中转,使 NAT/防火墙后的内网服务可被外部访问的技术,本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]:Caddy 作为反向代理,将公网 HTTPS 请求转发到本地 frp 映射端口,提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]:frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道,支持非 HTTP 协议(如 SSH、MySQL)
|
||||
- [[自动HTTPS]]:Caddy 内置 Let's Encrypt 证书自动申请和续期,无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]:Cloudflare DNS 配置,将子域名(如 nas.ishenwei.online)指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]:VPS 提供商(192.227.222.142),托管 frps 服务端和 Caddy 反向代理,作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]:内网 NAS 设备(192.168.3.17),运行 frpc 客户端,通过 frp 暴露 NAS 服务(5000端口 → VPS 15000)
|
||||
- [[frp]]:开源内网穿透工具,本方案的核心,包含 frps(服务端,监听 7000 端口)和 frpc(客户端),版本 0.65.0
|
||||
- [[Caddy]]:Go 语言编写的自动 HTTPS 反向代理服务器,与 frp 配合为内网服务提供 HTTPS 域名访问
|
||||
- [[Cloudflare]]:域名 DNS 托管服务商,通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](本文是该概览中内网穿透架构的详细展开)
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](FRP 安装是该方案的前置步骤)
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](Mac Mini FRP 客户端配置参考)
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]](Ubuntu Server 24.04 是本方案的目标操作系统)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点:
|
||||
- 冲突点:监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点:本文提供完整公网域名访问方案,包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点:监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置,未展开公网访问细节
|
||||
- 建议:在监控方案中补充指向本文内网穿透配置的外链,实现监控方案 + 公网访问的完整闭环
|
||||
|
||||
Reference in New Issue
Block a user