Angular 部署到 Firebase 后，如何修复自定义域名的 Google 登录回调？

2026-11-04数据阿明

结论

通常不需要给 Angular 配置“忽略路由”。/__/auth/handler 应由 Firebase Authentication 的认证辅助页面处理，前提是自定义域名正确接入了对应项目的 Firebase Hosting。

NG04002 表明 Angular Router 尝试匹配了这条路径。结合弹窗显示应用首页的现象，可以推测认证请求进入了 Angular 应用，但仅凭这个报错还不能确定问题是由域名配置、代理还是缓存造成的。

为什么调整 Angular 路由解决不了根本问题

浏览器加载 Angular 应用后，即使路由守卫拒绝导航，也不会自动把同一个请求交给 Firebase 认证处理器。为该路径添加空组件或将其重定向到首页，同样无法完成 OAuth 回调。

Firebase Hosting 对 /__/* 保留命名空间的处理优先于普通重定向和 SPA rewrite。因此，请求直接到达正确的 Firebase Hosting 服务时，常见的 ** → /index.html rewrite 通常不需要为认证路径增加例外。Firebase Hosting 响应优先级

按顺序检查配置

1. 确认自定义域名接入了正确的 Hosting 项目

在 Firebase Hosting 中确认 auth.example.com 已完成自定义域名绑定，并且属于当前应用使用的 Firebase Authentication 项目。仅配置 DNS 或将该域名重定向到应用首页，都不能提供认证处理端点。

Firebase 官方要求自定义 authDomain 接入使用同一认证项目的 Firebase Hosting。自定义认证域名配置

2. 确认 authDomain 只填写主机名

authDomain 的值应为：

auth.example.com

不要填写完整回调 URL：

https://auth.example.com/__/auth/handler

修改现有 Firebase 配置中的 authDomain 字段，其余配置保留原值。下面的 existingFirebaseConfig 代表项目原有的配置对象：

const firebaseConfig = {
  ...existingFirebaseConfig,
  authDomain: "auth.example.com"
};

在现有的 Firebase 或 AngularFire 初始化位置使用修改后的配置，并确认生产环境实际加载了这份配置。

3. 分别配置 Firebase 域名授权和 Google OAuth 回调地址

在 Firebase Authentication 的 Authorized domains 中添加 auth.example.com。如果应用实际运行在其他域名，也应确认该域名已获授权。
找到 Firebase Google 登录实际使用的 Google OAuth Web 客户端，在 Authorized redirect URIs 中添加以下完整地址：

https://auth.example.com/__/auth/handler

与 authDomain 字段不同，这里需要包含 https:// 和 /__/auth/handler。Firebase 的 Google 登录文档列出了这些自定义域名配置步骤。Google 登录自定义域名说明

配置正确后仍跳首页，如何定位

在登录弹窗的开发者工具中打开 Network，保留请求日志并重新触发登录，然后检查 /__/auth/handler 请求的响应内容和重定向链：

如果响应包含 Angular 的根元素和应用脚本，说明请求返回了应用入口页面，应继续检查实际提供响应的服务。
如果出现跳转到 / 的 HTTP 重定向，检查域名转发、CDN 或反向代理规则。
如果请求由 Service Worker 响应，先临时绕过或注销它，再重试，以判断导航回退是否拦截了认证路径。

如果应用启用了 PWA，Service Worker 的 navigation fallback 必须排除 Firebase 保留的 /__ 命名空间。Firebase 官方明确要求不要拦截这类请求。保留 URL 与 Service Worker

直接访问不带登录参数的 /__/auth/handler 时，可能出现认证参数相关错误，这本身不能证明端点配置失败。应结合真实登录请求判断，重点确认它没有返回 Angular 首页。

如果该域名实际上由其他服务器提供服务

如果 auth.example.com 的请求没有由 Firebase Hosting 处理，就需要在实际服务器上提供认证辅助端点。一种官方方案是将 /__/auth/ 下的 GET/POST 请求透明反向代理到当前项目的默认 Firebase 域名，并保留路径和查询参数。普通的 302 跳转不能替代这种代理。认证请求反向代理方案

目前缺少 Hosting、代理和 Service Worker 配置，无法确定具体是哪一层出了问题。优先核实自定义域名的实际请求去向，以及 /__/auth/handler 返回的内容，再调整对应配置。