Esta página fornece respostas para perguntas frequentes sobre o App Hosting.
App Hosting Perguntas frequentes
Limitações gerais do App Hosting e solução de problemas
- Devido a um problema na infraestrutura Cloud Run,
a criação ou atualização de recursos pode ser mais lenta do que
o esperado em algumas regiões, como
us-central1. Se a latência de implantação for um problema em uma região específica, o Google recomenda fazer a implantação em outra região. - A CDN do App Hosting só pode incluir um conjunto específico de cabeçalhos de solicitação nas chaves de cache. Essa lista inclui os cabeçalhos
RSC,Next-Router-State-Tree,Next-Router-Prefetch,Next-Router-Segment-PrefetcheNext-Urldo NextJS, além dos cabeçalhos padrão do Cloud CDNAccept,Accept-Encoding,Access-Control-Request-Headers,Access-Control-Request-Method,Origin,Sec-Fetch-Dest,Sec-Fetch-Mode,Sec-Fetch-Site,X-Goog-Allowed-ResourceseX-Origin. Se uma resposta contiver um cabeçalhoVarycom um valor não listado aqui, nossa CDN não o armazenará em cache. - Os arquivos estáticos sem cache são veiculados de Cloud Run. Em uma versão posterior, eles serão armazenados e veiculados da origem App Hosting para melhorar o desempenho.
- O console Firebase pode mostrar intermitentemente um erro "build não encontrado e inválido" na criação do back-end.
- Todos os back-ends no mesmo projeto compartilham uma organização/conta do GitHub. Elas podem estar conectadas a repositórios diferentes nessa organização/conta. Para criar back-ends conectados a contas diferentes do GitHub, coloque-os em projetos separados.
Limitações e solução de problemas do app Angular
Embora o suporte do App Hosting para Angular esteja em desenvolvimento e expansão, ele tem as seguintes limitações:
- I18n: embora a funcionalidade principal de I18n funcione, a navegação direta para páginas SSR pode resultar em erros.
- Localização: não é possível criar versões para diferentes localidades.
- Criadores: no momento, apenas o criador de aplicativos é compatível.
- Ambientes e ferramentas de monorepo: projetos do Angular que têm mais de um destino de aplicativo vão falhar. Para um suporte mais completo ao monorepo, use o Nx.
Erros HTTP 400 e confiança de proxy na renderização do lado do servidor do Angular
Se o aplicativo Angular implantado em Firebase App Hosting encontrar erros HTTP 400 (solicitação inválida), bloqueadores de validação de host ou falhas de confiança de proxy, siga a solução recomendada para sua versão do Angular:
- Angular v19, v20 e v21: há duas maneiras de resolver esses erros HTTP 400:
- Fazer upgrade das dependências: execute
npm update @angular/core @angular/ssrpara instalar a versão de patch mais recente da sua versão atual do Angular. - Configuração manual: aplique um fallback de configuração no nível do código
definindo
trustProxyHeaders: truena configuração do servidor. Consulte Configurar cabeçalhos de proxy confiáveis na documentação do Angular.
- Fazer upgrade das dependências: execute
- Angular v22: o primeiro build em um novo back-end pode retornar erros 400. Para resolver o problema, gere um segundo build. Todos os builds subsequentes devem funcionar conforme o esperado.
Limitações e solução de problemas do Next.js
- Por padrão, a otimização de imagens integrada do NextJS fica desativada no App
Hosting, a menos que você defina explicitamente
images.unoptimizedcomo "false" ou use um carregador de imagens personalizado.Consulte Otimizar o carregamento de imagens no Next.js. - Os caminhos de URL que contêm caracteres codificados por porcentagem são decodificados por Cloud Run. Isso pode causar problemas com recursos que esperam apenas caminhos de URL codificados, como o roteamento paralelo do Next.js.
- No momento, o App Hosting limita o armazenamento em cache para apps NextJS usando middleware. Com o tempo, as taxas de ocorrência em cache vão melhorar.
- Os caminhos de URL que contêm caracteres codificados por porcentagem são decodificados pelo Cloud Run. Isso pode causar problemas com recursos que esperam apenas caminhos de URL codificados, como roteamento paralelo do Next.js.