我猜你大概率也遇到过这个场景一台小主机吭哧吭哧把DeepSeek模型拉下来跑起来了终端里能对话了但也就你自己能玩。家里人想试两句得蹲在电脑前同事想看效果得凑过来敲键盘。本来想着“私有AI助手”结果变成了“单机版玩具”。dsh-pocket就是奔着解决这个问题来的。它是基于DeepSeek开源模型生态做的一个轻量Web封装部署好之后局域网里任何一部手机、平板、笔记本浏览器扫码就能直接用再往上走一步配合一条公网隧道人在外面也能随时访问家里这台私有助手。整个过程下来就是一条从“局域网扫码”到“公网隧道”的最短路径不需要在设备上装任何客户端也不用登录什么账号。这篇就顺着这条路手把手走一遍适合两类人一是已经在用Ollama/LM Studio跑本地模型、想把能力开放给局域网甚至外网的玩家二是小团队想在内部快速搭一个AI问答入口、但不想买云服务器的朋友。1. 项目全貌最短路径到底短在哪里1.1 先把dsh-pocket是什么搞清楚先说人话dsh-pocket就是一个把DeepSeek能力装进“口袋”的Web入口。它本身不做模型训练也不重新发明推理引擎而是把模型服务和一套极简的对话界面打包在一起让你本地部署后马上就能通过浏览器对话。它和Open WebUI这类重量级面板的区别在于——dsh-pocket刻意做了减法。没有用户注册、没有多租户、没有复杂的插件市场甚至连数据库都可以免掉。默认情况下就是一个单页对话界面加一个后端代理后端负责和本地模型或API打交道前端负责把回复渲染得干干净净。之所以做成这个形态是因为我发现大多数自建AI的人最终需求其实特别朴素能在手机浏览器里打开一个页面输入问题拿到回答。就这么简单。功能堆得越多部署和维护的成本就越高反而违背了“私有助手”的初衷。1.2 “最短路径”的设计思路一切以可达性为准这个项目的最佳实践路径拆开看就是三句话阶段一设备上电。Docker Compose一条命令拉起服务本机localhost能访问。阶段二局域网可达。固定IP生成二维码局域网任一设备扫码打开。阶段三公网可达。用隧道把内网端口映射到公网域名人不在家也能访问。这其实是把网络访问这条链路拆成了ABC三段每一段都有明确的判断标准能curl通就是成功curl不通就排查这一段。不绕弯不搞抽象架构出问题很好定位。我见过不少人在第一步就跑去折腾K8s、网关、鉴权结果一个月过去了连对话都没跑通。“最短路径”的底层思路其实是先让服务被访问到再谈优化任何步骤如果不能直接服务于“让手机能打开并对话”这个目标就先放一放。1.3 谁适合走这条路谁不适合适合走这条路的人大致有这几类已经有一台能跑DeepSeek本地模型的机器哪怕是最小量化版本想在办公室或家里把AI能力小范围开放给几个人手里有公网VPS想做一个随时可达的私有AI入口以及那些不想在手机、平板上装任何客户端的人。不适合的人也要说清楚想要复杂用户管理、多角色权限的企业场景这个项目没做这块想基于商业大模型API做高并发转发的也不该用这种轻量封装完全没碰过命令行的人需要先补一点基础不过跟着本文一步步来问题也不大。这个定位很重要。如果你属于“不适合”的那类趁早换方案别浪费时间。2. 局域网部署先把服务拉起来2.1 硬件要求和镜像选型跑dsh-pocket硬件门槛完全取决于你用哪个模型。如果后端接的是deepseek-r1:7b这类量化模型建议至少8GB内存的机器。CPU可以跑但速度一般如果有块NVIDIA显卡体验会舒服很多。我实测在7840HS核显小主机上7b量化模型的速度属于“能对话但不是秒回”的水平日常问答完全能接受。如果不想本地跑模型也可以把dsh-pocket配置成走DeepSeek官方API这样对硬件几乎没要求——但注意走API之后“离线可用”这个卖点就没了看你自己权衡。本文以本地模型为例讲API模式只是改一个base_url 和一个key的事后面会顺带提到。2.2 Docker Compose一条命令拉起服务我用的是Docker Compose方式部署整体结构非常清晰。先把目录建好mkdir -p ~/dsh-pocket cd ~/dsh-pocket然后创建docker-compose.ymlservices: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ./models:/root/.ollama ports: - 11434:11434 restart: unless-stopped dsh-pocket: image: dsh-pocket:latest container_name: dsh-pocket depends_on: - ollama ports: - 8888:80 environment: - OLLAMA_BASE_URLhttp://ollama:11434 - MODEL_NAMEdeepseek-r1:7b restart: unless-stopped两个服务一个跑Ollama作为推理后端一个跑dsh-pocket的Web界面。dsh-pocket通过环境变量拿到Ollama的地址和默认模型名宿主机上只暴露8888端口给前端页面。拉取并启动docker compose up -d首次启动会拉镜像。Ollama那边不会自动下载模型需要在容器里手动拉一次docker exec -it ollama ollama pull deepseek-r1:7b这里有个很多人会踩的坑Ollama镜像默认不带模型必须执行一次pull我第一次就卡在这一步。模型体积不小7b量化版大概4.7GB耐心等就行。2.3 本机验证三板斧启动完成后验证三步走# 1. 看容器状态 docker compose ps # 2. 本机访问Web界面 curl -I http://localhost:8888 # 3. 确认Ollama模型列表 curl http://localhost:11434/api/tags如果容器都是Up状态curl返回200模型列表里有deepseek-r1:7b说明本机已经跑通。这时候你在宿主机上打开 http://localhost:8888 就能看到对话页面了。别急着高兴你现在只是完成了“本机可达”离“扫码可用”还差一个局域网IP的设置。3. 扫码访问手机浏览器直接打开对话页3.1 固定局域网IP告别“IP老变”的玄学手机扫码能不能成功第一条命脉就是IP地址。如果宿主机是DHCP动态分配IP你可能今天扫码还能打开、明天就404因为IP变了。在Linux下我习惯用NetworkManager的nmcli固定IPnmcli con mod Wired connection 1 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual nmcli con up Wired connection 1注意把连接名替换成你自己的用nmcli con show可以查看。固定IP之后重启也不会变后面生成的二维码就永远有效。如果你不想改配置也可以去路由器后台做DHCP静态绑定二选一即可但这件事一定要做否则二维码很可能变成一次性的。查当前局域网IPLinux用ip addrWindows用ipconfig。手机和宿主机必须在同一个Wi-Fi网段下这是硬前提。3.2 一条命令生成访问二维码拿到固定IP和端口后生成二维码有很多种方式我推荐终端直接生成这才是“最短路径”该有的样子echo http://192.168.1.100:8888 | qrencode -o - -t ANSIUTF8前提是装一下qrencodesudo apt install qrencode这个命令会在终端里直接输出一个ASCII二维码用手机相机或者微信扫一下就能打开。如果你想保存成图片发给同事加一个输出参数echo http://192.168.1.100:8888 | qrencode -o ~/dsh-pocket-access.png -t PNG -s 8生成的PNG放在一个大家都方便拿到的地方或者直接打印贴在主机上。如果你不想装qrencode也可以用Python一行实现import qrcode qrcode.make(http://192.168.1.100:8888).save(dsh-pocket-access.png)扫码后手机浏览器打开页面能看到对话界面局域网这一段就算彻底打通了。3.3 为什么二维码比让用户敲URL更靠谱说白了这属于“用户体验的最后一米”。在电脑前测试的时候打开localhost天经地义但让人家掏出手机还输入192.168.1.100这么一串多数人两三遍都输不对甚至会打个192.168.1.1就来问你怎么回事。二维码把网络地址变成了“看一眼、扫一下”的动作。在手机相机原生支持扫码识别的今天二维码就是最快触达服务的媒介没有之一。另外有个细节iOS相机默认扫码后会用Safari打开http链接Android的微信也可以直接识别。如果页面打不开或者提示不安全去查防火墙和端口占用具体排查方法见第6章。4. 公网隧道把私有助手带到办公室以外4.1 隧道方案选型frp、cpolar、ngrok怎么选到了公网这一段本质问题是多数宽带的公网IP不是你想有就有的即使有80和443端口大概率被运行商限制。所以“直接端口映射”在多数场景里行不通得靠隧道——让一台有公网IP的服务器帮你把流量转进来。隧道工具常见三件套我直接整理成表格供你参考方案上手难度自定义域名传输性能适合场景frp中等支持高自建有VPS、追求长期稳定cpolar低支持需注册中不想搭服务器、快速体验ngrok低支持需注册中临时演示、快速测试我推荐frp原因很直接一旦你有了VPSfrp是完全自部署的流量不经过任何第三方中转域名和端口都自己控制长期跑最稳。cpolar和ngrok适合临时演示免费版的域名随机变不适合做固定入口。追求省事可以先用cpolar体验确定要长期用再迁到frp也不迟。4.2 frp服务端和客户端配置实战假设你有一台VPS公网IP是1.2.3.4。在服务器上下载frp服务端以linux amd64为例wget https://github.com/fatedier/frp/releases/download/v0.58.0/frp_0.58.0_linux_amd64.tar.gz tar -zxf frp_0.58.0_linux_amd64.tar.gz cd frp_0.58.0_linux_amd64编辑frps.tomlbindPort 7000 auth.token 换成你自己的强密码 dashboardPort 7500 dashboardUser admin dashboardPwd 换成你自己的密码 vhostHTTPPort 8080启动服务端./frps -c frps.toml本地小主机作为客户端下载对应架构的frp客户端版本编辑frpc.tomlserverAddr 1.2.3.4 serverPort 7000 auth.token 换成你自己的强密码 [[proxies]] name dsh-pocket type http localIP 127.0.0.1 localPort 8888 customDomains dsh.yourdomain.com启动客户端./frpc -c frpc.toml此时在VPS的DNS解析里把 dsh.yourdomain.com 指向1.2.3.4访问 http://dsh.yourdomain.com:8080 就相当于访问家里小主机的8888端口了。这里要分清一个概念VPS上vhostHTTPPort8080表示外部统一通过8080进入frp再按域名规则转发到内网的8888。所以完整访问地址是 http://dsh.yourdomain.com:8080不是直接访问443或80。4.3 HTTPS证书与访问入口的细节HTTP裸奔肯定不行尤其要外出访问时中间任何一层网络设备都能看到明文对话内容。frp本身不终止TLS我的做法是在VPS上再用Caddy做一层反向代理把 http://dsh.yourdomain.com:8080 代理成 https://dsh.yourdomain.com证书用ACME自动签发。Caddy配置极简两行搞定dsh.yourdomain.com { reverse_proxy 127.0.0.1:8080 }执行caddy runCaddy会自动申请并续签证书浏览器地址栏就能看到小锁头了。这里要强调不要图省事用自签证书。iOS和Android对自签证书的信任处理完全不同给非技术用户用的话一个“此连接非私人”的告警就足够劝退所有人。Caddy自动签发的证书体验最好没有之一。另外别忘了给frp和Caddy都加上systemd守护否则VPS一重启服务就没了。frp的systemd单元文件官方包里自带Caddy安装官方deb包后也会自动注册服务这两件事都要做。5. 联动优化从局域网到公网的无缝切换5.1 双入口设计内网走内网外网走隧道有了隧道之后你会发现一个有趣的问题同一台小主机在家里用二维码访问 http://192.168.1.100:8888 是最快的出了门就得访问 https://dsh.yourdomain.com。两个地址不一样体验上有点割裂。这其实是正常且合理的。内网流量在局域网里直连延迟低、带宽大公网流量绕道VPS中转链路长这是物理规律没必要强行统一入口。我的做法是保留双入口二维码上的局域网地址贴在家里家人用HTTPS域名存在手机浏览器书签里自己出外网用。两条路各自稳定互不干扰。如果有人非要在家里走公网域名当然也能访问只是会绕一圈VPS完全没必要。5.2 隧道守护掉线自动重连就靠systemdfrp客户端长期运行后偶尔会因为网络抖动断开。虽然frp自带重连逻辑但“偶尔抽风”这件事一旦发生在你正在外面远程使用的时候就很烦。我在客户端上加了一层systemd守护[Unit] Descriptionfrp client Afternetwork-online.target [Service] Typesimple ExecStart/home/user/frp/frpc -c /home/user/frp/frpc.toml Restartalways RestartSec5 [Install] WantedBymulti-user.target进程退出后5秒自动重启。VPS端和本机端的这两个服务都放进systemd并enable开机自启基本能做到“长期无感运行”。我实测挂了大半个月除了VPS迁移IP那一次手动重启过其余时间都很稳定。5.3 资源占用与功耗控制小主机7x24小时运行功耗和资源占用是绕不开的话题。dsh-pocket本身Web界面很轻主要资源开销在Ollama和模型推理。我实测过一组数据核显小主机空载时整机功耗约15W模型加载但无请求时也差不多一旦开始跑对话CPU占用立刻上到80%以上功耗冲到25到30W。如果你只是给家里人偶尔用可以考虑让Ollama在空闲时卸载模型curl http://localhost:11434/api/generate -d {model:deepseek-r1:7b,keep_alive:0}这样模型会在空闲后自动释放内存下次请求再重新加载。内存紧张的小主机用这个配置非常实用。还有一条网络层面的经验端口别开太多。公网方向只需要暴露VPS的8080或443端口小主机本机的8888不要暴露到公网保持“主动出站、被动不入站”的安全姿态。安全这块会在下一章详细说。6. 常见问题与排查技巧实录6.1 局域网扫码打不开页面的排查清单扫码后打不开90%的情况跑不出下面这几条逐条对一遍手机和宿主机不在同一网段。这是最常见的手机连了5G流量、宿主机插着网线两边不在一个局域网里自然扫不通。先确认手机Wi-Fi和宿主机在同一个路由器下。防火墙拦截。Linux的ufw或firewalld默认可能挡了8888端口执行sudo ufw allow 8888或者sudo firewall-cmd --add-port8888/tcp --permanent然后reload。端口绑定错了。Docker端口映射是“宿主机8888→容器80”如果你直接访问容器IP的80端口在部分网络插件下会不通。认准宿主机IP加8888。IP地址变了。尤其DHCP环境先用ip addr确认当前IP是不是你二维码里那个变了就再生成一次。手机浏览器对明文HTTP的限制。部分安卓系统浏览器会拦截明文HTTP改用Chrome或者去浏览器设置里允许不安全内容。排查顺序建议先Ping通不通再telnet 8888通不通再curl -I通不通。逐层递进不要一上来就怀疑应用本身。6.2 隧道频繁断流先别急着重启隧道断流出现时先别慌着重启frp按下面的顺序查看日志journalctl -u frpc -f或者直接看frp客户端控制台输出。如果出现EOF或timeout大多是网络抖动。查VPS的入站连接数ss -s。连接数异常高可能有扫描流量进来了把frp的bindPort换成一个高位随机端口。检查域名解析。有时候不是隧道断了而是你的DNS把域名解析到了旧IP刷新一下解析记录就好。确认VPS安全组放行了7000和8080端口。云服务商安全组忘配是典型的“鸟笼问题”——服务端明明在跑外部就是连不上。分享一个实用小技巧在隧道域名后面加一个/healthz健康检查端点配合UptimeRobot这类监控工具断线5分钟就能收到通知不用等用户来报障。6.3 安全加固的几条底线最后说安全。这一块我不敢说全面但下面几条是底线碰都不要碰frp的auth.token务必用强随机字符串不要用123456这种这种token等于给VPS开了后门。VPS防火墙只放行必要端口SSH、frp服务端的7000、反向代理的80/443其余全部DROP。dsh-pocket如果后续版本支持访问口令建议开启哪怕一个共享密码也能挡住绝大多数扫描器。不要在公网暴露Ollama的11434端口绝对不要。这个端口一旦暴露别人可以随意拉取你的模型甚至执行操作。定期更新frp和dsh-pocket镜像。这类项目迭代不算慢老版本可能会有已修复的坑跟着升级主要是为了省心。安全配置不是一次搞定就一劳永逸的事至少每个月看一眼防火墙规则有没有意外的新条目花不了两分钟。从局域网扫码到公网隧道这条路走完整理下来我个人实际折腾的体感是真正花时间的不是部署本身而是理解每一步为什么这么做——为什么要在扫码之前固定IP为什么隧道要配VPS端和本地端两个systemd服务为什么优先用Caddy签发HTTPS证书而不是自签。把这些阶段性的“为什么”想透后面无论是换模型、换VPS还是换隧道工具你都能快速迁移过去。最后分享一个小技巧如果家里有多台设备都要跑类似服务不妨把dsh-pocket的二维码打印出来贴在主机边上顺手标上“内网访问”和“外网访问”两个地址。家人同事问起来指一下就好不用每次手忙脚乱地翻聊天记录找链接。这大概就是“最短路径”在生活里的样子——不是技术上的最短而是别人用起来的最短。
我猜你大概率也遇到过这个场景一台小主机吭哧吭哧把DeepSeek模型拉下来跑起来了终端里能对话了但也就你自己能玩。家里人想试两句得蹲在电脑前同事想看效果得凑过来敲键盘。本来想着“私有AI助手”结果变成了“单机版玩具”。dsh-pocket就是奔着解决这个问题来的。它是基于DeepSeek开源模型生态做的一个轻量Web封装部署好之后局域网里任何一部手机、平板、笔记本浏览器扫码就能直接用再往上走一步配合一条公网隧道人在外面也能随时访问家里这台私有助手。整个过程下来就是一条从“局域网扫码”到“公网隧道”的最短路径不需要在设备上装任何客户端也不用登录什么账号。这篇就顺着这条路手把手走一遍适合两类人一是已经在用Ollama/LM Studio跑本地模型、想把能力开放给局域网甚至外网的玩家二是小团队想在内部快速搭一个AI问答入口、但不想买云服务器的朋友。1. 项目全貌最短路径到底短在哪里1.1 先把dsh-pocket是什么搞清楚先说人话dsh-pocket就是一个把DeepSeek能力装进“口袋”的Web入口。它本身不做模型训练也不重新发明推理引擎而是把模型服务和一套极简的对话界面打包在一起让你本地部署后马上就能通过浏览器对话。它和Open WebUI这类重量级面板的区别在于——dsh-pocket刻意做了减法。没有用户注册、没有多租户、没有复杂的插件市场甚至连数据库都可以免掉。默认情况下就是一个单页对话界面加一个后端代理后端负责和本地模型或API打交道前端负责把回复渲染得干干净净。之所以做成这个形态是因为我发现大多数自建AI的人最终需求其实特别朴素能在手机浏览器里打开一个页面输入问题拿到回答。就这么简单。功能堆得越多部署和维护的成本就越高反而违背了“私有助手”的初衷。1.2 “最短路径”的设计思路一切以可达性为准这个项目的最佳实践路径拆开看就是三句话阶段一设备上电。Docker Compose一条命令拉起服务本机localhost能访问。阶段二局域网可达。固定IP生成二维码局域网任一设备扫码打开。阶段三公网可达。用隧道把内网端口映射到公网域名人不在家也能访问。这其实是把网络访问这条链路拆成了ABC三段每一段都有明确的判断标准能curl通就是成功curl不通就排查这一段。不绕弯不搞抽象架构出问题很好定位。我见过不少人在第一步就跑去折腾K8s、网关、鉴权结果一个月过去了连对话都没跑通。“最短路径”的底层思路其实是先让服务被访问到再谈优化任何步骤如果不能直接服务于“让手机能打开并对话”这个目标就先放一放。1.3 谁适合走这条路谁不适合适合走这条路的人大致有这几类已经有一台能跑DeepSeek本地模型的机器哪怕是最小量化版本想在办公室或家里把AI能力小范围开放给几个人手里有公网VPS想做一个随时可达的私有AI入口以及那些不想在手机、平板上装任何客户端的人。不适合的人也要说清楚想要复杂用户管理、多角色权限的企业场景这个项目没做这块想基于商业大模型API做高并发转发的也不该用这种轻量封装完全没碰过命令行的人需要先补一点基础不过跟着本文一步步来问题也不大。这个定位很重要。如果你属于“不适合”的那类趁早换方案别浪费时间。2. 局域网部署先把服务拉起来2.1 硬件要求和镜像选型跑dsh-pocket硬件门槛完全取决于你用哪个模型。如果后端接的是deepseek-r1:7b这类量化模型建议至少8GB内存的机器。CPU可以跑但速度一般如果有块NVIDIA显卡体验会舒服很多。我实测在7840HS核显小主机上7b量化模型的速度属于“能对话但不是秒回”的水平日常问答完全能接受。如果不想本地跑模型也可以把dsh-pocket配置成走DeepSeek官方API这样对硬件几乎没要求——但注意走API之后“离线可用”这个卖点就没了看你自己权衡。本文以本地模型为例讲API模式只是改一个base_url 和一个key的事后面会顺带提到。2.2 Docker Compose一条命令拉起服务我用的是Docker Compose方式部署整体结构非常清晰。先把目录建好mkdir -p ~/dsh-pocket cd ~/dsh-pocket然后创建docker-compose.ymlservices: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ./models:/root/.ollama ports: - 11434:11434 restart: unless-stopped dsh-pocket: image: dsh-pocket:latest container_name: dsh-pocket depends_on: - ollama ports: - 8888:80 environment: - OLLAMA_BASE_URLhttp://ollama:11434 - MODEL_NAMEdeepseek-r1:7b restart: unless-stopped两个服务一个跑Ollama作为推理后端一个跑dsh-pocket的Web界面。dsh-pocket通过环境变量拿到Ollama的地址和默认模型名宿主机上只暴露8888端口给前端页面。拉取并启动docker compose up -d首次启动会拉镜像。Ollama那边不会自动下载模型需要在容器里手动拉一次docker exec -it ollama ollama pull deepseek-r1:7b这里有个很多人会踩的坑Ollama镜像默认不带模型必须执行一次pull我第一次就卡在这一步。模型体积不小7b量化版大概4.7GB耐心等就行。2.3 本机验证三板斧启动完成后验证三步走# 1. 看容器状态 docker compose ps # 2. 本机访问Web界面 curl -I http://localhost:8888 # 3. 确认Ollama模型列表 curl http://localhost:11434/api/tags如果容器都是Up状态curl返回200模型列表里有deepseek-r1:7b说明本机已经跑通。这时候你在宿主机上打开 http://localhost:8888 就能看到对话页面了。别急着高兴你现在只是完成了“本机可达”离“扫码可用”还差一个局域网IP的设置。3. 扫码访问手机浏览器直接打开对话页3.1 固定局域网IP告别“IP老变”的玄学手机扫码能不能成功第一条命脉就是IP地址。如果宿主机是DHCP动态分配IP你可能今天扫码还能打开、明天就404因为IP变了。在Linux下我习惯用NetworkManager的nmcli固定IPnmcli con mod Wired connection 1 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual nmcli con up Wired connection 1注意把连接名替换成你自己的用nmcli con show可以查看。固定IP之后重启也不会变后面生成的二维码就永远有效。如果你不想改配置也可以去路由器后台做DHCP静态绑定二选一即可但这件事一定要做否则二维码很可能变成一次性的。查当前局域网IPLinux用ip addrWindows用ipconfig。手机和宿主机必须在同一个Wi-Fi网段下这是硬前提。3.2 一条命令生成访问二维码拿到固定IP和端口后生成二维码有很多种方式我推荐终端直接生成这才是“最短路径”该有的样子echo http://192.168.1.100:8888 | qrencode -o - -t ANSIUTF8前提是装一下qrencodesudo apt install qrencode这个命令会在终端里直接输出一个ASCII二维码用手机相机或者微信扫一下就能打开。如果你想保存成图片发给同事加一个输出参数echo http://192.168.1.100:8888 | qrencode -o ~/dsh-pocket-access.png -t PNG -s 8生成的PNG放在一个大家都方便拿到的地方或者直接打印贴在主机上。如果你不想装qrencode也可以用Python一行实现import qrcode qrcode.make(http://192.168.1.100:8888).save(dsh-pocket-access.png)扫码后手机浏览器打开页面能看到对话界面局域网这一段就算彻底打通了。3.3 为什么二维码比让用户敲URL更靠谱说白了这属于“用户体验的最后一米”。在电脑前测试的时候打开localhost天经地义但让人家掏出手机还输入192.168.1.100这么一串多数人两三遍都输不对甚至会打个192.168.1.1就来问你怎么回事。二维码把网络地址变成了“看一眼、扫一下”的动作。在手机相机原生支持扫码识别的今天二维码就是最快触达服务的媒介没有之一。另外有个细节iOS相机默认扫码后会用Safari打开http链接Android的微信也可以直接识别。如果页面打不开或者提示不安全去查防火墙和端口占用具体排查方法见第6章。4. 公网隧道把私有助手带到办公室以外4.1 隧道方案选型frp、cpolar、ngrok怎么选到了公网这一段本质问题是多数宽带的公网IP不是你想有就有的即使有80和443端口大概率被运行商限制。所以“直接端口映射”在多数场景里行不通得靠隧道——让一台有公网IP的服务器帮你把流量转进来。隧道工具常见三件套我直接整理成表格供你参考方案上手难度自定义域名传输性能适合场景frp中等支持高自建有VPS、追求长期稳定cpolar低支持需注册中不想搭服务器、快速体验ngrok低支持需注册中临时演示、快速测试我推荐frp原因很直接一旦你有了VPSfrp是完全自部署的流量不经过任何第三方中转域名和端口都自己控制长期跑最稳。cpolar和ngrok适合临时演示免费版的域名随机变不适合做固定入口。追求省事可以先用cpolar体验确定要长期用再迁到frp也不迟。4.2 frp服务端和客户端配置实战假设你有一台VPS公网IP是1.2.3.4。在服务器上下载frp服务端以linux amd64为例wget https://github.com/fatedier/frp/releases/download/v0.58.0/frp_0.58.0_linux_amd64.tar.gz tar -zxf frp_0.58.0_linux_amd64.tar.gz cd frp_0.58.0_linux_amd64编辑frps.tomlbindPort 7000 auth.token 换成你自己的强密码 dashboardPort 7500 dashboardUser admin dashboardPwd 换成你自己的密码 vhostHTTPPort 8080启动服务端./frps -c frps.toml本地小主机作为客户端下载对应架构的frp客户端版本编辑frpc.tomlserverAddr 1.2.3.4 serverPort 7000 auth.token 换成你自己的强密码 [[proxies]] name dsh-pocket type http localIP 127.0.0.1 localPort 8888 customDomains dsh.yourdomain.com启动客户端./frpc -c frpc.toml此时在VPS的DNS解析里把 dsh.yourdomain.com 指向1.2.3.4访问 http://dsh.yourdomain.com:8080 就相当于访问家里小主机的8888端口了。这里要分清一个概念VPS上vhostHTTPPort8080表示外部统一通过8080进入frp再按域名规则转发到内网的8888。所以完整访问地址是 http://dsh.yourdomain.com:8080不是直接访问443或80。4.3 HTTPS证书与访问入口的细节HTTP裸奔肯定不行尤其要外出访问时中间任何一层网络设备都能看到明文对话内容。frp本身不终止TLS我的做法是在VPS上再用Caddy做一层反向代理把 http://dsh.yourdomain.com:8080 代理成 https://dsh.yourdomain.com证书用ACME自动签发。Caddy配置极简两行搞定dsh.yourdomain.com { reverse_proxy 127.0.0.1:8080 }执行caddy runCaddy会自动申请并续签证书浏览器地址栏就能看到小锁头了。这里要强调不要图省事用自签证书。iOS和Android对自签证书的信任处理完全不同给非技术用户用的话一个“此连接非私人”的告警就足够劝退所有人。Caddy自动签发的证书体验最好没有之一。另外别忘了给frp和Caddy都加上systemd守护否则VPS一重启服务就没了。frp的systemd单元文件官方包里自带Caddy安装官方deb包后也会自动注册服务这两件事都要做。5. 联动优化从局域网到公网的无缝切换5.1 双入口设计内网走内网外网走隧道有了隧道之后你会发现一个有趣的问题同一台小主机在家里用二维码访问 http://192.168.1.100:8888 是最快的出了门就得访问 https://dsh.yourdomain.com。两个地址不一样体验上有点割裂。这其实是正常且合理的。内网流量在局域网里直连延迟低、带宽大公网流量绕道VPS中转链路长这是物理规律没必要强行统一入口。我的做法是保留双入口二维码上的局域网地址贴在家里家人用HTTPS域名存在手机浏览器书签里自己出外网用。两条路各自稳定互不干扰。如果有人非要在家里走公网域名当然也能访问只是会绕一圈VPS完全没必要。5.2 隧道守护掉线自动重连就靠systemdfrp客户端长期运行后偶尔会因为网络抖动断开。虽然frp自带重连逻辑但“偶尔抽风”这件事一旦发生在你正在外面远程使用的时候就很烦。我在客户端上加了一层systemd守护[Unit] Descriptionfrp client Afternetwork-online.target [Service] Typesimple ExecStart/home/user/frp/frpc -c /home/user/frp/frpc.toml Restartalways RestartSec5 [Install] WantedBymulti-user.target进程退出后5秒自动重启。VPS端和本机端的这两个服务都放进systemd并enable开机自启基本能做到“长期无感运行”。我实测挂了大半个月除了VPS迁移IP那一次手动重启过其余时间都很稳定。5.3 资源占用与功耗控制小主机7x24小时运行功耗和资源占用是绕不开的话题。dsh-pocket本身Web界面很轻主要资源开销在Ollama和模型推理。我实测过一组数据核显小主机空载时整机功耗约15W模型加载但无请求时也差不多一旦开始跑对话CPU占用立刻上到80%以上功耗冲到25到30W。如果你只是给家里人偶尔用可以考虑让Ollama在空闲时卸载模型curl http://localhost:11434/api/generate -d {model:deepseek-r1:7b,keep_alive:0}这样模型会在空闲后自动释放内存下次请求再重新加载。内存紧张的小主机用这个配置非常实用。还有一条网络层面的经验端口别开太多。公网方向只需要暴露VPS的8080或443端口小主机本机的8888不要暴露到公网保持“主动出站、被动不入站”的安全姿态。安全这块会在下一章详细说。6. 常见问题与排查技巧实录6.1 局域网扫码打不开页面的排查清单扫码后打不开90%的情况跑不出下面这几条逐条对一遍手机和宿主机不在同一网段。这是最常见的手机连了5G流量、宿主机插着网线两边不在一个局域网里自然扫不通。先确认手机Wi-Fi和宿主机在同一个路由器下。防火墙拦截。Linux的ufw或firewalld默认可能挡了8888端口执行sudo ufw allow 8888或者sudo firewall-cmd --add-port8888/tcp --permanent然后reload。端口绑定错了。Docker端口映射是“宿主机8888→容器80”如果你直接访问容器IP的80端口在部分网络插件下会不通。认准宿主机IP加8888。IP地址变了。尤其DHCP环境先用ip addr确认当前IP是不是你二维码里那个变了就再生成一次。手机浏览器对明文HTTP的限制。部分安卓系统浏览器会拦截明文HTTP改用Chrome或者去浏览器设置里允许不安全内容。排查顺序建议先Ping通不通再telnet 8888通不通再curl -I通不通。逐层递进不要一上来就怀疑应用本身。6.2 隧道频繁断流先别急着重启隧道断流出现时先别慌着重启frp按下面的顺序查看日志journalctl -u frpc -f或者直接看frp客户端控制台输出。如果出现EOF或timeout大多是网络抖动。查VPS的入站连接数ss -s。连接数异常高可能有扫描流量进来了把frp的bindPort换成一个高位随机端口。检查域名解析。有时候不是隧道断了而是你的DNS把域名解析到了旧IP刷新一下解析记录就好。确认VPS安全组放行了7000和8080端口。云服务商安全组忘配是典型的“鸟笼问题”——服务端明明在跑外部就是连不上。分享一个实用小技巧在隧道域名后面加一个/healthz健康检查端点配合UptimeRobot这类监控工具断线5分钟就能收到通知不用等用户来报障。6.3 安全加固的几条底线最后说安全。这一块我不敢说全面但下面几条是底线碰都不要碰frp的auth.token务必用强随机字符串不要用123456这种这种token等于给VPS开了后门。VPS防火墙只放行必要端口SSH、frp服务端的7000、反向代理的80/443其余全部DROP。dsh-pocket如果后续版本支持访问口令建议开启哪怕一个共享密码也能挡住绝大多数扫描器。不要在公网暴露Ollama的11434端口绝对不要。这个端口一旦暴露别人可以随意拉取你的模型甚至执行操作。定期更新frp和dsh-pocket镜像。这类项目迭代不算慢老版本可能会有已修复的坑跟着升级主要是为了省心。安全配置不是一次搞定就一劳永逸的事至少每个月看一眼防火墙规则有没有意外的新条目花不了两分钟。从局域网扫码到公网隧道这条路走完整理下来我个人实际折腾的体感是真正花时间的不是部署本身而是理解每一步为什么这么做——为什么要在扫码之前固定IP为什么隧道要配VPS端和本地端两个systemd服务为什么优先用Caddy签发HTTPS证书而不是自签。把这些阶段性的“为什么”想透后面无论是换模型、换VPS还是换隧道工具你都能快速迁移过去。最后分享一个小技巧如果家里有多台设备都要跑类似服务不妨把dsh-pocket的二维码打印出来贴在主机边上顺手标上“内网访问”和“外网访问”两个地址。家人同事问起来指一下就好不用每次手忙脚乱地翻聊天记录找链接。这大概就是“最短路径”在生活里的样子——不是技术上的最短而是别人用起来的最短。
