chore: sync local project changes
This commit is contained in:
Shen Wei
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：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，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + 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 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## 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）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[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-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：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，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + 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 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## 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）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[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