App Engine Flexible配置dispatch.yaml后careco子域名仍指向默认服务

你遇到的情况挺常见的——dispatch.yaml显示已生效，但careco.xxxxxxxxx.com还是跳转到default服务，而另一个子域名正常。咱们从几个常见的排查点入手：

首先先确认你的dispatch.yaml配置（方便对照）：

dispatch:
  - url: "wscfg.xxxxxxxxx.com/"
    service: default
  - url: "onboarding.xxxxxxxxx.com/"
    service: default
  - url: "dtnote.xxxxxxxxx.com/"
    service: default
  - url: "careco.xxxxxxxxx.com/"
    service: careco
  - url: "userman.xxxxxxxxx.com/"
    service: user-management

1. 修正URL匹配规则的前缀问题 #

注意你配置里的careco.xxxxxxxxx.com/末尾的斜杠——这个规则只会精确匹配根路径的请求（比如https://careco.xxxxxxxxx.com/），但如果用户访问时浏览器自动去掉了斜杠，或者请求了子路径（比如https://careco.xxxxxxxxx.com/login），就会匹配不到这条规则，转而使用default服务。

把规则改成带通配符的形式，覆盖该域名下的所有请求：

- url: "careco.xxxxxxxxx.com/*"
  service: careco

重新部署dispatch.yaml：

gcloud app deploy dispatch.yaml

2. 确认自定义域名的绑定范围 #

要确保careco.xxxxxxxxx.com是绑定到整个App Engine项目，而不是单独绑定到default服务。你可以在App Engine控制台的「自定义域名」页面检查：

• 找到careco.xxxxxxxxx.com的条目，确认它的「服务/版本」列显示的是「所有服务」，而不是「default」。如果是绑定到了default服务，dispatch规则会被覆盖。

3. 验证生效的dispatch规则 #

用gcloud命令查看当前实际生效的dispatch配置，确认careco的规则已经正确部署：

gcloud app dispatch describe

输出里应该能看到careco.xxxxxxxxx.com/*（或者你修改后的规则）对应的service是careco，如果看不到，说明部署可能没成功，检查部署时的命令输出有没有错误。

4. 排除缓存干扰 #

浏览器缓存或者App Engine的边缘缓存可能会导致旧的路由规则仍然生效。试试：

• 用无痕/隐私模式访问careco.xxxxxxxxx.com
• 或者在URL后加随机参数（比如https://careco.xxxxxxxxx.com/?test=123）绕开缓存
• 也可以在App Engine控制台的「版本」页面，对careco服务的版本执行「清除缓存」操作

5. 核对服务名称的一致性 #

确认你部署的服务名称确实是careco——App Engine服务名称是大小写敏感的（通常都是小写），检查：

• 部署careco服务时的app.yaml里的service: careco配置是否正确
• 在App Engine控制台的「服务」页面，是否存在名为careco的服务，没有拼写错误（比如少了字母、多了下划线等）

按照上面的步骤排查后，应该能解决careco.xxxxxxxxx.com指向错误的问题。

内容的提问来源于stack exchange，提问作者Vikas