Linux
最近我在折腾一个很实际的问题： 我有一台内网机器，上面跑着很多服务，每个服务都有自己的端口。现在我想把其中某些服务暴露到公网，让外部可以访问。 这个需求很常见。 比如我家里或者局域网里有一台 Ubuntu 机器，上面跑着： MCP 服务：8120 API 服务：8122 测试后台：8080 某个 Go 服务：9000 某个 Python 服务：7860 这些服务本身都在内网里，外部是访问不到的。 如果机器没有公网 IP，或者路由器不方便做端口映射，那传统方式就很麻烦。于是我用了 frp。 一开始我对 frp 的理解还比较简单： 它就是一个内网穿透工具，可以把内网端口暴露到公网服务器上。 但真正跑通之后，我对它的理解一步一步升级了。 一、frp 的核心逻辑：公网服务器帮内网机器“代收连接” frp 的结构其实很清晰： 外部用户
部署运维
记录一次从零开始部署 frp 的完整过程，包括原理理解、架构设计、踩坑排查，以及最终跑通的全流程。 背景 我有一台内网服务器，上面跑着一些本地服务（监听在 8900 端口）。同时我有一台云服务器，有公网 IP，上面已经用 Caddy 跑了一堆服务。 需求很简单：让公网能访问到我内网服务器上的服务。 方案：frp（Fast Reverse Proxy）—— 一个专注于内网穿透的反向代理工具。 frp 是什么 frp 由两个组件构成： * frps（server）：部署在有公网 IP 的服务器上 * frpc（client）：部署在内网机器上 它的工作原理： 1. frps 在公网服务器上启动，监听一个"控制端口"（默认 7000），等待客户端连接
AI
最近把一套 Embedding 服务完整落地了一遍：4 张显卡分别启动 vLLM 实例，用 Nginx 做统一入口和故障切换，再在上层挂一个 FastAPI 网关，把原始向量统一裁剪成 256 维并归一化，最终形成一套比较完整、可直接对外提供服务的 Embedding 架构。 这篇文章把整个过程完整整理一下，包含环境准备、离线模型部署、多卡启动、Nginx 配置、systemd 开机自启，以及业务网关设计。 整套架构的目标很明确： * 提供标准 HTTP Embeddings API * 支持四卡并行 * 支持统一入口与负载均衡 * 单实例故障时自动 failover * 支持开机自启 * 保留日志，便于运维与统计 一、整体架构 先看整体结构： Client │ ▼ FastAPI Gateway（8681） ← 推荐对外入口 │ ▼ Nginx（
陕公网安备61011302002223号