Cloud Run自定义cloud.run地址进入预览：短地址更易分享，删除映射会释放名称

10-01 3阅读

2026年9月28日，Google Cloud公布Cloud Run自定义URL预览，可为服务创建更易记的cloud.run子域名，公告称无需配置DNS、负载均衡或支付该功能的额外费用。这里的短地址属于Google管理的域名，服务自身的使用与计费仍应单独评估。

AI概念配图，非真实界面/产品。

网址方便了，生命周期仍要有人负责

官方文档列出默认每项目50个映射，子域名长6至63个字符；限制为内部入口的服务不受支持，Terraform也尚不支持。删除映射后名称会立即开放给其他用户申请，删除底层服务却不会自动释放映射。关闭默认run.app地址也不会关闭自定义地址。

本文认为，这项功能适合演示、试用和轻量服务分享，但发布前需要想清楚网址会出现在哪里。一次会议里口头展示的地址，与印在长期文档或客户材料中的地址，对稳定性的要求不同。入口越容易记住，使用者也越可能把它保存下来。

建议先确定命名规则，区分试验、演示和长期服务，避免把临时测试占用的名字宣传成永久入口。名称本身可以表达用途，但不宜依赖某个人的记忆来判断它属于谁；管理记录里应保留服务、项目和维护负责人。

新地址能够打开，并不意味着它已具备恰当的访问控制。本文建议在发布链接前，分别用预期用户和未授权访问者的场景检查结果，确认应用实际呈现的页面符合设计。登录回跳、回调地址和前端请求来源也应随着入口一起核对。

如果系统已有多个访问地址，最好列出完整入口清单。停用某个旧入口后，再从外部逐一验证剩余入口的状态，避免只检查一个地址就判断整个服务不可访问。这里的检查重点是自己的部署结果，而不是猜测某个开关是否联动了所有入口。

对外分享之前，还可以从另一台设备打开链接，检查页面、静态资源和需要登录的操作是否都能完成。部署者自己的浏览器可能保留了会话或缓存，单凭本机访问成功容易漏掉新访客会遇到的问题。

由于映射删除会使名称重新可被申请，本文建议先清点仍引用它的文档、通知和客户端，再安排退场。旧链接若继续流传，用户可能把后来出现在同名地址上的内容误认为原服务。这个风险来自地址生命周期，不能只靠应用代码处理。

若准备把试验转为长期服务，应先评估预览状态和现有自动化方式是否满足维护要求。把入口变短确实能减少沟通摩擦，但不能把尚未支持的部署路径写入正式承诺，或假设未来迁移没有改动成本。

一次完整交付至少应留下地址用途、允许访问的人、底层服务位置和退出安排。这样短网址才能成为可靠入口，而不是一个几个月后已经无人记得归属的书签。

本文于北京时间2026年10月1日核验。新闻事实来自上述官方资料，文中使用判断与实施建议为本站独立分析，后续状态以官方更新为准。