如果你也习惯在服务器上跑 Claude Code 做开发那“远程预览”这步的痛应该体会过不止一次。改完页面想发给同事验收对方却打不开你本地的 localhost你得先去下载隧道工具、注册账号、手动绑定端口、复制一串又长又难记的地址——然后 Claude Code 已经在等你下一轮指令了。最近我在社区翻到一个小插件正好把这套流程里最烦的那一步收进了一条命令里今天聊聊它到底是怎么做到的。这个插件的思路很简单它不做花哨的界面只专注解决“让外部的人访问到本地开发中的 Web 服务”这一件事。安装在全局后你在 Claude Code 启动应用的终端里多敲一条命令就能拿到一个公网可访问的临时链接手机上扫码也能直接打开。如果你的工作流也是“SSH 到服务器或远程机器 - 跑 Claude Code - 写完代码想让别人看到效果”那这个东西值得花五分钟试试。1. 远程预览为什么会让 Claude Code 用户抓狂1.1 问题不是“没有公网 IP”而是操作链路太长很多人一开始以为远程预览难是因为自己没有公网 IP、路由器不能端口映射、服务器防火墙挡得严。但实际做开发的时候真正让人烦的不是网络层的门槛而是整套操作链路的长度。传统方案我试过几种自己买台云服务器、手工配 Nginx 反向代理、再部署一个内网穿透客户端。这套流程对长期项目来说是正解但对开发中那种“就想让同事看一眼当前效果”的场景有点小题大做。你真正需要的是“临时的、用完就扔的、别人能打开的预览地址”而不是一套长期维护的基础设施。每次为了一分钟预览去改一遍 Nginx 配置怎么说都不划算。ngrok、cloudflared 这类成熟工具我也用过质量没问题但它们和 Claude Code 的工作流是割裂的。你得先记住当前应用跑在哪个端口再手动输一条隧道命令拿到一段随机域名复制发给别人。听起来不难但你回忆一下一天里“起服务 - 调试 - 改完再给人看”这个循环会发生多少次就会明白每一次“切换窗口、敲命令、核对端口”都是心流的中断。1.2 隧道工具与终端工作流的割裂Claude Code 是个终端原生的 AI 编码工具它的使用场景大多在服务器、容器、或者远处的一台开发机上你通过 SSH 连上去操作。这个时候你面对的是纯命令行环境没有浏览器界面也没有 VSCode 那样的“端口转发”按钮即便你用 VSCode Remote也得依赖图形客户端。在这种环境下隧道工具的体验就变得很尴尬。有些工具需要你先登录账号需要浏览器完成一次 OAuth 认证结果你在服务器上根本没有图形浏览器卡在登录那一步就要折腾半天。有的工具安装没问题但生成的随机域名每次都变同事上次收藏的链接第二天就失效了。还有的工具比较吃配置在低配云服务器上一跑就占掉不少资源。更麻烦的是Claude Code 启动的开发服务端口往往是动态的。你让它起一个 Next.js 项目它可能跑在 3000让它起一个 Vite 项目可能变成 5173如果某个端口被占用Claude 还会自动换到下一个。你永远不能预判这次到底该转发哪个端口必须先去问一下、看一下输出再复制端口号去敲命令。1.3 为什么“最烦的一步”其实是端口和隧道之间的摩擦回过头看整个流程最烦的那一步恰恰就是把隧道命令和当前服务端口做“对齐”的瞬间。你需要在两个系统之间来回切换一个是 Claude Code 正在运行的开发服务器另一个是独立的隧道工具。这个操作单看每次只要十几秒但它的摩擦在于“心智负荷”。你本来满脑子都是代码逻辑突然要切换到“基础设施操作模式”去记端口、复制链接。一天重复十几次之后你会潜意识里开始逃避给别人看预览能不演示就不演示这其实是开发体验里一个很实际的问题。所以一个真正适配 Claude Code 的远程预览插件不应该要求你改变现有工作流而是应该主动去发现端口、自动建链、把结果直接吐在终端里。谁做到这一步谁就真正解决了那“最烦的一步”。这也是我最初看到那个小插件时眼前一亮的原因。2. 小插件解决的关键一步从“手动折腾”到“一条命令”2.1 插件的定位不是隧道服务而是工作流胶水这个插件不是自己搭建了一套全新的隧道网络它本质上是一个“终端胶水层”负责把你本地的开发服务端口、隧道工具的启动、公网链接的生成、以及二维码的输出打包成一个自动化动作。你可以把插件想象成一个懂行的助理你不需要告诉它“请用 xx 隧道把 xx 端口映射出去”你只需要说“我要预览”它自己去判断该用哪个端口、该调起哪个通道最后把结果放在你面前。Claude Code 的用户最怕的就是工具逼着自己做决策而这个插件的设计目标恰恰是把决策拿走。2.2 核心逻辑自动发现端口然后生成临时公网地址插件的工作流程大致分三步。第一步扫描本机正在监听的端口过滤掉系统服务和数据库进程重点识别常见的开发服务器特征。第二步根据进程名、端口号、常见框架默认端口做打分排序选出最可能的那个 Web 服务端口。第三步调用内网隧道组件建立一个安全的转发链路把公网临时域名和本地端口绑定然后把可访问的地址打印到终端。我在实际使用中验证过大部分情况下它的默认选择都是对的。如果哪天它猜错了你也可以用-p参数手动指定。这个设计很聪明不要求你每次手动输入但给了你兜底方案。2.3 和传统方案的直观对比方案安装成本是否需要离开终端端口识别方式链接稳定性移动端访问自建服务器 Nginx高需要运维是手动配置稳定可用需自己适配ngrok 手动隧道中需要注册是手动输入免费版链接会变可用cloudflared 临时隧道中是手动输入每次随机可用VSCode 端口转发中依赖图形端部分半自动依赖 VSCode 在线较弱这个插件低npm 一条命令否自动发现临时链接可用时长可配置直接扫码这个对比让我们看到前面几种方案各自都有被诟病的地方而这个插件没有在传输速度上有质的飞跃它强在“把所有杂事吞掉了把体验做顺了”。对一个日常开发工具来说顺就是最大的效率。3. 安装与上手把插件跑起来的完整过程3.1 安装为什么我用全局安装而不是装到项目里安装方式很简单用 npm 全局安装即可。我以目前用的这个封装为例它在 npm 上的包名是cc-preview不同作者维护的版本命令可能略有差异但核心使用逻辑是共通的。npm install -g cc-preview我没有把它装到某个具体项目里因为远程预览这件事和项目本身没有绑定关系——今天可能预览 A 项目明天预览 B 项目全局安装可以保证在任何目录下都能直接使用。而且 Claude Code 本身是 Node 生态终端工具的全局安装路径对 SSH 用户来说也最省心。如果你用的机器同时有好几个 Node 版本记得安装到当前node -v对应的全局路径下避免装完了命令找不到。装完验证一下cc-preview --version能输出版本号说明环境没问题。3.2 核心命令实际上只要记三条就够这个插件命令虽然有不少参数但日常真正高频用到的只有三条。第一条是自动模式不接任何参数直接让它自己找端口cc-preview第二条是指定端口模式适合它自动识别不准、或者你明确知道服务在哪个端口的情况cc-preview -p 3000第三条是带二维码的模式适合需要手机访问的场景cc-preview --qr还有一个参数我觉得很贴心是给隧道命名方便你区分同时开的多个预览cc-preview -p 5173 --name frontend-demo启动之后终端里会打印一行公网链接格式类似https://随机字符串.tmp-domain.dev链接保持多长时间取决于你用的后端通道配置一般默认短时有效足够一次演示或验收。3.3 与 Claude Code 的配合一个真实的操作现场我实际的使用场景通常是这样的在服务器上进入项目目录启动 Claude Code让它写功能、修 bug。写完一段可以展示的功能后我让它启动开发服务器启动 Next.js 开发服务端口保持默认接着我不等 Claude 输出完直接另开一个终端面板或者按终端分割快捷键执行cc-preview收到链接后发给同事对方浏览器打开就能看到页面我在 Claude Code 里继续改代码改完保存对方刷新页面就能看到新效果。整个过程我不需要离开终端不需要打开任何网页后台不需要复制端口号。如果项目是前后端分离前端一个端口、后端一个端口也有办法一次起多条隧道cc-preview -p 5173 --name web cc-preview -p 3001 --name api两条命令分别拿到两个公网地址前端地址发给做页面验收的人后端地址发给调接口的人互不干扰。3.4 把它做成 Claude Code 的快捷指令用了几次之后我嫌每次手动敲命令还是有点多余于是把预览动作直接写进了 Claude Code 的项目说明文件里。具体做法是在项目的CLAUDE.md中加一条当用户需要展示当前页面时先运行 npm run dev 启动开发服务器 然后用 cc-preview --qr 生成公网预览链接把公网地址告诉用户。这样连手动敲命令都省了只需要在对话里对 Claude 说“预览一下”它会自己起服务、自己调插件、把链接贴给我。这个组合用起来非常顺相当于把一个完整的“开发 - 展示 - 反馈”闭环收进了自然语言里。4. 插件的工作原理它是怎么知道该转发哪个端口的4.1 端口自动发现的背后是一套启发式规则很多第一次用的人都会好奇它怎么知道该转发哪个端口其实原理并不神秘用的是很朴素的启发式探测。插件先读取当前系统里所有处于监听状态的 TCP 端口这一步在 Linux 上可以读/proc/net/tcp在 macOS 上可以执行lsof -iTCP -sTCP:LISTEN拿到一批端口列表。然后它对每个端口的进程做画像进程名是多少、是不是 node / python / java / go 这类常见开发语言、有没有命令行参数指向常见框架比如vite、next dev、react-scripts、是不是明显和 Web 服务相关。最后还有一个高分规则常见的 Web 开发端口3000、5173、8080、8000、8888、3001会被给予额外权重。你本地通常同时跑着一堆服务数据库占了 3306、Redis 占了 6379、SSH 占了 22插件会在打分时把这些明显不是网页服务的端口过滤掉。这个过滤逻辑看起来简单却是整个自动发现功能体验好坏的分水岭做不好就会出现把 Redis 端口当网页端口转发出去的尴尬。4.2 公网链接是怎么建立的门卫传话模式拿到本地端口后插件要做的下一件事是建立公网访问链路。它会在本地起一个轻量的转发客户端与远端的中转节点建立一条长期连接通常走 TLS 加密的 TCP 或 WebSocket中转节点分配一个临时子域名。之后的工作方式很像小区门卫传话访客访问临时域名请求到中转节点节点把请求“原封不动”地通过长连接传给本地客户端本地客户端把请求转发给本地真实服务端口拿到 HTTP 响应后再沿原路返回。访客看到的页面内容实际上是从你本机动态渲染出来的代码改动刷新就能看到因为这个链路本身不做缓存。这个过程里大多数用户感知不到因为插件把整条链路封装在了后台。你只看到终点结果一条公网地址。但只要理解了这条链路你就知道一个很重要的边界——预览时的流量经过中转节点页面的加载速度取决于你本机到节点之间的链路质量而不是插件本身的魔法。4.3 为什么二维码是这个插件最“懂行”的细节我最初以为二维码只是个锦上添花的彩蛋直到有一次我在外面用手机看效果才意识到这个细节的价值。开发者在电脑上预览天经地义但现实里经常会有这样的需求你在手机浏览器里验证一个表单好不好填、一个按钮点击区域够不够大、一个页面在窄屏下会不会崩。传统做法是拿到链接后把那一长串随机域名手动输进手机浏览器那个过程堪比当年背 Wi-Fi 密码。而--qr参数直接把你从“手工输入长域名”的深渊里救了出来。这个细节说明插件作者真实经历过开发预览的场景而不是只从技术文档里理解需求。工具类产品最动人的地方往往就是这样的小细节它不用你说就知道你想要什么。4.4 安全边界临时链接不等于绝对安全必须泼一盆冷水的是这类隧道插件生成的临时公网链接本质上是把你的本地服务短暂暴露在了公网上。虽然临时域名里通常带着一段随机 token外部扫描很难猜到但如果你本地服务本身没有鉴权任何拿到链接的人都能直接访问全部内容。我自己的习惯是非敏感项目才用这种隧道预览涉及客户数据、密钥、生产环境配置的项目一律不碰。插件也提供了一些防护参数比如可以给隧道加访问口令cc-preview --auth admin:preview123加了之后访客打开链接会先弹一个浏览器基础认证框输入正确的账号密码才能看到内容。这个参数挡不住高手但至少能避免链接误转发后被无关人员点开。日常开发预览有这层防护基本够用了。5. 实测场景远程验收、手机调试和多端口共存5.1 场景一同事远程验收页面不再发压缩包前阵子我帮一个朋友做一个活动页面对方的运营同事在另一个城市非要“先看看效果再定”。按以前的方式我可能要把 dist 目录压缩、传到对象存储、再开个静态网站托管一套流程走下来页面什么样子早就忘记了。这次我用了这个插件先让 Claude Code 把页面适配改完确认本地效果无误然后启动预览把公网链接用微信发过去。不到一分钟那边就回复了“第三屏的按钮颜色再深一点”。我改完代码本地开发服务器热更新对方刷新页面立刻看到了新版配色。这个场景最让我满意的地方是一条链接解决了一次跨地域的即时反馈而且不需要对方安装任何工具、不需要登录、不需要注册。用“发链接”这种最朴素的方式完成了协作所有复杂度都被插件吞掉了。5.2 场景二手机端调试二维码直接扫码移动端适配是前端开发里绕不开的环节。之前我的做法是先把页面部署到一个测试环境再用手机访问或者用 Chrome DevTools 的设备模拟模式凑合看。但模拟模式永远代替不了真机尤其是下拉刷新、软键盘弹起、物理像素渲染这些行为模拟器根本测不出来。现在我会在 Claude Code 完成改动后顺手执行cc-preview --qr然后用手机对准屏幕扫码浏览器直接打开预览页面。整个调试循环可以压缩到“改代码 - 扫码刷新 - 再看问题”三步。如果你同时测多个页面可以用--name参数给每条隧道起不同名字手机浏览器里就不会收藏一堆分辨不清的随机域名了。5.3 场景三前端后端两个服务各开各的隧道联调场景有个老问题前端跑在 5173后端跑在 3001如果只把前端隧道公开前端页面里的 API 请求会发到 localhost同事打开页面看到的是一堆接口报错。这个插件对多端口的管理思路是“每条隧道独立”不是把所有端口打包成一个入口。你可以分别开启两条隧道然后把前端日志里的 API 地址改成后端隧道的公网地址。这样同事打开页面前端资源从第一条隧道加载接口请求打到第二条隧道联调功能能跑通。当然这种方式比打包方案要手动多配一步但带来了更大的灵活性。对于临时预览需求这个代价可以接受。如果需要更复杂的多端口聚合或者自定义域名转发那就该考虑上专门的网关工具了这个小插件不是为那个场景设计的。5.4 场景四给 AI Agent 的 Webhook 回调提供一个入口最近在玩 AI Agent 的自动化经常需要让远程服务回调到本地调试接口。有些平台的 Webhook 地址必须是公网可访问的 URL否则没法触发。换以前我只好把回调逻辑部署到服务器上调试改一次部署一次效率极低。现在我用cc-preview -p 8000起一个隧道把本地的 Webhook 接收接口暴露出去把公网地址填到平台后台。平台触发事件时HTTP POST 请求会通过隧道打到本地。本地代码有修改进程自动重启下一次回调立即生效。这套方案把“改代码 - 看效果”的周期缩短到了几秒。6. 边界与避坑使用小插件前必须知道的事6.1 免费通道的时效、速度与稳定性使用这类隧道插件默认走的通常是公共中转节点。好处是免费、免注册、开箱即用代价是临时域名有时效短则几十分钟、长则数小时过期后链接就失效了需要重新生成。如果你的演示时间比较长记得注意链接剩余有效时间提前续上一条新隧道。速度方面公共节点的带宽是共享的网络高峰时段打开预览页面的加载速度会有波动。如果你只是给同事看静态页面、简单交互效果问题不大但如果你预览的是几百 MB 的视频或高频实时请求的应用公共节点会明显吃力。这种情况建议把插件配置成自建通道指向你自己的一台有公网 IP 的服务器速度和稳定性立刻不一样。6.2 网络链路质量对国内开发者的影响由于中转节点可能部署在离你较远的区域本地到节点之间的链路质量会直接影响预览体验。如果你和我一样日常开发机在国内服务器或本地电脑上建议第一次使用时做个简单测试启动预览后打开页面看看首屏加载速度是否在可接受范围内。如果发现链路太慢除了自建节点还有一个笨办法把 Claude Code 的开发环境搬到你网络覆盖更好的机器上让应用跑在链路条件更优的地方。反正 Claude Code 本身支持远程环境迁移成本不高。这个小插件解决的是流程摩擦链路质量问题建议从网络层面根治。6.3 关不干净的进程一个小坑插件用完后有些人会直接关闭终端窗口以为隧道就断了。大部分情况下确实是断了但我遇到过几次直觉上的“残留”问题早先的隧道进程没有完全退出端口还被占用或者下次执行时提示地址已被使用。遇到这种情况不需要去翻进程表直接执行cc-preview stop这个命令会把当前用户下残留的预览转发进程统一清理干净。我养成的习惯是每次预览结束顺手敲一下stop比直接关窗口更靠谱。还有个细节如果你被多个端口绑定问题困扰执行完stop再重新启动通常能解决大半。6.4 它不是生产环境的部署工具这个小插件再好用它的定位始终是“开发预览”不是“生产环境部署”。生产环境你需要的是稳定域名、全链路监控、流量治理、自动扩缩容这些指望一个终端小插件是不现实的。我自己对工具的选择有一条标准要清楚每个工具该在哪个环节发光。Claude Code 负责生成代码和解决研发问题这个小插件负责把“给别人看当前效果”这个步骤做到零摩擦而真正的线上部署交给专业流水线。工具之间分工明确用起来才不会拧巴。最后的几个小建议翻了不少插件之后我对这类“小工具”的态度一直是值得装但别神化。这个插件解决的是远程预览里最烦的一步它不会让 Claude Code 写出更好的代码也不会让你免掉部署流程但它能把“展示”这个动作从几分钟压缩到几秒钟一天下来攒出来的时间足够你多跑一轮调试。我自己的搭配习惯是这样的在 CLAUDE.md 里把预览指令固化下来让 Claude 可以直接调起手机收藏夹里存好二维码扫描器每次结束预览后统一跑一次cc-preview stop清理残留。这套流程跑了半个多月没有再因为“给别人看看效果”这件事打断过开发思路。如果你也经常被这个问题卡住不妨装一个试试。反正安装成本就一条命令不值当花十分钟去纠结试了不好用再卸掉也不迟。