chore: sync local project changes
This commit is contained in:
Shen Wei
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（frps + Caddy）建立反向隧道，使内网服务（NAS、Ubuntu）可通过 `*.ishenwei.online` 域名从公网安全访问。
|
||||
- 问题域：家庭内网设备无公网 IP，无法被外网直接访问；需要将内网服务通过公网 VPS 暴露为 HTTPS 域名。
|
||||
- 方法/机制：frp（frps 服务端 + frpc 客户端）建立 TCP 反向隧道 → VPS 本地端口映射 → Caddy 反向代理到对应端口并自动申请 Let's Encrypt HTTPS 证书。
|
||||
- 结论/价值：完整的内网穿透方案，支持 NAS、n8n、Transmission、Grafana、Navidrome、Calibre、WebDAV 等多个服务，附 SSH 穿透和故障排查指南。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板，比纯 SSH 隧道更适合多设备多端口场景。
|
||||
- Caddy 自动处理 Let's Encrypt 证书申请和续期，无需手动配置 HTTPS。
|
||||
- SSH 穿透（TCP 映射）不经过 Caddy，只依赖 frps + frpc 配置。
|
||||
- 故障排查核心：确认 frps 监听端口正确、token 一致、防火墙放行 7000 端口、frps 日志无 token mismatch。
|
||||
|
||||
## Key Quotes
|
||||
> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — 方案选型说明
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — HTTPS 配置结果
|
||||
> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理。" — SSH vs HTTP 穿透关键区别
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — 常见故障根因
|
||||
|
||||
## Key Concepts
|
||||
- [[反向代理]]：Caddy 将公网请求反向代理到 VPS 本地 frp 映射端口（127.0.0.1:xxxxx）。
|
||||
- [[内网穿透]]：通过 frp 反向隧道穿透 NAT/防火墙，使内网设备可被公网访问。
|
||||
- [[TCP隧道]]：frp 将内网 TCP 端口映射到 VPS remote_port，实现任意 TCP 协议穿透。
|
||||
- [[Caddy]]：Go 语言反向代理服务器，自动 HTTPS（Let's Encrypt），Caddyfile 配置各子域名反向代理到对应 frp 端口。
|
||||
- [[frp]]：开源内网穿透工具，frps（服务端）监听 7000 端口，frpc（客户端）建立反向隧道。
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd]]：VPS 提供商（IP: 192.227.222.142），托管 frps 和 Caddy，作为内网穿透公网中转站。
|
||||
- [[Synology NAS DS718]]：群晖 NAS（192.168.3.17），运行 NAS 管理界面（5000）、Navidrome（4533）、Calibre（8083）、WebDAV（5005）等服务，通过 frpc 映射到 VPS。
|
||||
- [[Ubuntu]]（内网 Ubuntu1 192.168.3.47）：运行 n8n（5678）、Transmission（9091）、Grafana（3000）、SSH（22），通过 frpc 映射到 VPS。
|
||||
- [[n8n]]：自动化工作流工具（192.168.3.47:5678），通过 frp 暴露为 `https://n8n.ishenwei.online`。
|
||||
- [[阿里云-DNS]]：管理 `ishenwei.online` 域名解析，A 记录指向 VPS 公网 IP。
|
||||
|
||||
## Connections
|
||||
- [[frp]] ← reverse_tunnel ← [[Synology NAS DS718]]（frpc 客户端，映射 5000→15000）
|
||||
- [[frp]] ← reverse_tunnel ← [[Ubuntu]]（frpc 客户端，映射 5678/9091/3000/22）
|
||||
- [[Caddy]] ← reverse_proxy ← [[frp]]（反向代理到 frp 映射的本地端口）
|
||||
- [[阿里云-DNS]] ← DNS_record ← [[RackNerd]]（A 记录指向 VPS IP 192.227.222.142）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu安装FRP操作笔记]] 冲突：
|
||||
- 冲突点：两者都描述 frp 安装，但侧重不同。
|
||||
- 当前观点：本文档（通过VPS+内网反向代理）侧重完整方案（frps+VPS+Caddy+多服务+SSH穿透+故障排查），是完整的操作指南。
|
||||
- 对方观点：[[Ubuntu安装FRP操作笔记]] 侧重 FRP 本身安装配置（frps.ini/frpc.ini 详解），偏向 FRP 工具参考手册。
|
||||
- 说明：两者互补，本文档是完整实践指南，对方是工具参考，两者不存在实质矛盾。
|
||||
---
|
||||
title: "通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（frps + Caddy）建立反向隧道，使内网服务（NAS、Ubuntu）可通过 `*.ishenwei.online` 域名从公网安全访问。
|
||||
- 问题域：家庭内网设备无公网 IP，无法被外网直接访问；需要将内网服务通过公网 VPS 暴露为 HTTPS 域名。
|
||||
- 方法/机制：frp（frps 服务端 + frpc 客户端）建立 TCP 反向隧道 → VPS 本地端口映射 → Caddy 反向代理到对应端口并自动申请 Let's Encrypt HTTPS 证书。
|
||||
- 结论/价值：完整的内网穿透方案，支持 NAS、n8n、Transmission、Grafana、Navidrome、Calibre、WebDAV 等多个服务，附 SSH 穿透和故障排查指南。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板，比纯 SSH 隧道更适合多设备多端口场景。
|
||||
- Caddy 自动处理 Let's Encrypt 证书申请和续期，无需手动配置 HTTPS。
|
||||
- SSH 穿透（TCP 映射）不经过 Caddy，只依赖 frps + frpc 配置。
|
||||
- 故障排查核心：确认 frps 监听端口正确、token 一致、防火墙放行 7000 端口、frps 日志无 token mismatch。
|
||||
|
||||
## Key Quotes
|
||||
> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — 方案选型说明
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — HTTPS 配置结果
|
||||
> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理。" — SSH vs HTTP 穿透关键区别
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — 常见故障根因
|
||||
|
||||
## Key Concepts
|
||||
- [[反向代理]]：Caddy 将公网请求反向代理到 VPS 本地 frp 映射端口（127.0.0.1:xxxxx）。
|
||||
- [[内网穿透]]：通过 frp 反向隧道穿透 NAT/防火墙，使内网设备可被公网访问。
|
||||
- [[TCP隧道]]：frp 将内网 TCP 端口映射到 VPS remote_port，实现任意 TCP 协议穿透。
|
||||
- [[Caddy]]：Go 语言反向代理服务器，自动 HTTPS（Let's Encrypt），Caddyfile 配置各子域名反向代理到对应 frp 端口。
|
||||
- [[frp]]：开源内网穿透工具，frps（服务端）监听 7000 端口，frpc（客户端）建立反向隧道。
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd]]：VPS 提供商（IP: 192.227.222.142），托管 frps 和 Caddy，作为内网穿透公网中转站。
|
||||
- [[Synology NAS DS718]]：群晖 NAS（192.168.3.17），运行 NAS 管理界面（5000）、Navidrome（4533）、Calibre（8083）、WebDAV（5005）等服务，通过 frpc 映射到 VPS。
|
||||
- [[Ubuntu]]（内网 Ubuntu1 192.168.3.47）：运行 n8n（5678）、Transmission（9091）、Grafana（3000）、SSH（22），通过 frpc 映射到 VPS。
|
||||
- [[n8n]]：自动化工作流工具（192.168.3.47:5678），通过 frp 暴露为 `https://n8n.ishenwei.online`。
|
||||
- [[阿里云-DNS]]：管理 `ishenwei.online` 域名解析，A 记录指向 VPS 公网 IP。
|
||||
|
||||
## Connections
|
||||
- [[frp]] ← reverse_tunnel ← [[Synology NAS DS718]]（frpc 客户端，映射 5000→15000）
|
||||
- [[frp]] ← reverse_tunnel ← [[Ubuntu]]（frpc 客户端，映射 5678/9091/3000/22）
|
||||
- [[Caddy]] ← reverse_proxy ← [[frp]]（反向代理到 frp 映射的本地端口）
|
||||
- [[阿里云-DNS]] ← DNS_record ← [[RackNerd]]（A 记录指向 VPS IP 192.227.222.142）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu安装FRP操作笔记]] 冲突：
|
||||
- 冲突点：两者都描述 frp 安装，但侧重不同。
|
||||
- 当前观点：本文档（通过VPS+内网反向代理）侧重完整方案（frps+VPS+Caddy+多服务+SSH穿透+故障排查），是完整的操作指南。
|
||||
- 对方观点：[[Ubuntu安装FRP操作笔记]] 侧重 FRP 本身安装配置（frps.ini/frpc.ini 详解），偏向 FRP 工具参考手册。
|
||||
- 说明：两者互补，本文档是完整实践指南，对方是工具参考，两者不存在实质矛盾。
|
||||
|
||||
Reference in New Issue
Block a user