As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas de conectividade do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que você pode enfrentar com a conectividade do App Mesh.
## Não é possível resolver o nome DNS para um serviço virtual
**Sintomas**
A aplicação não consegue resolver o nome DNS de um serviço virtual ao qual está tentando se conectar.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte o problema [Nome VirtualServices por qualquer nome de host ou FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub . Os serviços virtuais no App Mesh podem ter qualquer nome. Desde que haja um registro DNS `A` para o nome do serviço virtual e a aplicação possa resolver o nome do serviço virtual, a solicitação será intermediada por proxy pelo Envoy e roteada para seu destino apropriado. Para resolver o problema, adicione um registro DNS `A` a qualquer endereço IP não loopback, como `10.10.10.10`, para o nome do serviço virtual. O registro DNS `A` pode ser adicionado nas seguintes condições:
+ No Amazon Route 53, se o nome for sufixado pelo nome da sua zona hospedada privada
+ Dentro do arquivo `/etc/hosts` do contêiner da aplicação
+ Em um servidor DNS de terceiros que você gerencia
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um back-end de serviço virtual
**Sintomas**
Sua aplicação não consegue estabelecer uma conexão com um serviço virtual definido como back-end em seu nó virtual. Ao tentar estabelecer uma conexão, a conexão pode falhar completamente ou a solicitação, do ponto de vista da aplicação, pode falhar com um código de resposta `HTTP 503`.
**Resolução**
Se a aplicação não conseguir se conectar (nenhum código de resposta `HTTP 503` retornado), faça o seguinte:
+ Certifique-se de que seu ambiente computacional tenha sido configurado para funcionar com o App Mesh.
+ Para o Amazon ECS, certifique-se de que a [configuração de proxy](proxy-authorization.md) apropriada esteja habilitada. Para ver um end-to-end passo a passo, consulte [Getting Started with App Mesh e Amazon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html) ECS.
+ Para o Kubernetes, incluindo o Amazon EKS, certifique-se de ter o mais recente controlador do App Mesh instalado via Helm. Para obter mais informações, consulte [Controlador do App Mesh](https://hub.helm.sh/charts/aws/appmesh-controller) no Helm Hub ou [Tutorial: Configurar a integração do App Mesh com o Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ Para o Amazon EC2, certifique-se de configurar sua instância do Amazon EC2 para fazer proxy de tráfego do App Mesh. Para obter mais informações, consulte [Atualizar serviço](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services).
+ Certifique-se de que o contêiner Envoy que está sendo executado em seu serviço de computação tenha se conectado com êxito ao serviço de gerenciamento do App Mesh Envoy. É possível confirmar isso verificando as estatísticas do Envoy para o campo `control_plane.connected_state`. Para obter mais informações sobre o `control_plane.connected_state`, consulte [Monitorar a conectividade do proxy Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) em nossas **melhores práticas de solução de problemas**.
Se o Envoy conseguiu estabelecer a conexão inicialmente, mas depois foi desconectado e nunca reconectado, consulte [Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) para solução de problemas sobre motivo pelo qual ele foi desconectado.
Se a aplicação se conectar, mas a solicitação falhar com um código de resposta `HTTP 503`, tente o seguinte:
+ Certifique-se de que o serviço virtual ao qual você está se conectando exista na malha.
+ Certifique-se de que o serviço virtual tenha um provedor (um roteador virtual ou um nó virtual).
+ Ao usar o Envoy como um proxy HTTP, se estiver vendo tráfego de saída chegando em `cluster.cds_egress_*_mesh-allow-all` ao invés do destino correto dos dados estatísticos do Envoy, é muito provável que o Envoy não esteja roteando corretamente as solicitações `filter_chains`. Isso pode ser resultado do uso de um nome de serviço virtual não qualificado. Recomendamos usar o nome de descoberta de serviços real como nome do serviço virtual, pois o proxy Envoy se comunica com outros serviços virtuais por meio de seus nomes.
Para obter mais informações, consulte [serviços virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html).
+ Inspecione os logs do proxy do Envoy em busca de qualquer uma das seguintes mensagens de erro:
+ `No healthy upstream`: o nó virtual para o qual o proxy Envoy está tentando rotear não tem nenhum endpoint resolvido ou não tem nenhum endpoint íntegro. Certifique-se de que o nó virtual de destino tenha as configurações corretas de descoberta de serviços e verificação de integridade.
Se as solicitações para o serviço falharem durante uma implantação ou escalonamento do serviço virtual de back-end, siga as orientações em [Algumas solicitações falham com o código de status HTTP `503` quando um serviço virtual tem um provedor de nó virtual](#ts-connectivity-virtual-node-provider).
+ `No cluster match for URL`: isso provavelmente é causado quando uma solicitação é enviada para um serviço virtual que não corresponde aos critérios definidos por nenhuma das rotas definidas em um provedor de roteador virtual. Certifique-se de que as solicitações doa aplicação sejam enviadas para uma rota compatível, garantindo que o caminho e os cabeçalhos da solicitação HTTP estejam corretos.
+ `No matching filter chain found`: isso provavelmente é causado quando uma solicitação é enviada para um serviço virtual em uma porta inválida. Verifique se as solicitações da aplicação estão usando a mesma porta especificada no roteador virtual.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um serviço externo
**Sintomas**
Sua aplicação não consegue se conectar a um serviço fora da malha, como o `amazon.com`.
**Resolução**
Por padrão, o App Mesh não permite tráfego de saída de aplicações dentro da malha para nenhum destino fora da malha. Para habilitar a comunicação com um serviço externo, há duas opções:
+ Definir o [filtro de saída](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) no recurso de malha como `ALLOW_ALL`. Essa configuração permitirá que qualquer aplicação dentro da malha se comunique com qualquer endereço IP de destino dentro ou fora da malha.
+ Modele o serviço externo na malha usando um serviço virtual, roteador virtual, rota e nó virtual. Por exemplo, para modelar o serviço externo do `example.com`, você pode criar um serviço virtual chamado `example.com` com um roteador virtual e uma rota que envia todo o tráfego para um nó virtual com um nome de host de descoberta de serviços DNS de `example.com`.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um servidor MySQL ou SMTP
**Sintomas**
Ao permitir tráfego de saída para todos os destinos (Mesh `EgressFilter type`=`ALLOW_ALL`), como um servidor SMTP ou um banco de dados MySQL usando uma definição de nó virtual, a conexão do seu aplicativo falha. Como exemplo, a seguir está uma mensagem de erro da tentativa de conexão com um servidor MySQL.
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Resolução**
Esse é um problema conhecido que é resolvido com o uso da imagem do App Mesh versão 1.15.0 ou posterior. Para obter mais informações, consulte o problema [Não é possível se conectar ao MySQL com o App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62) GitHub . Este erro ocorre porque o receptor de saída no Envoy configurado pelo App Mesh adiciona o filtro de receptor Inspetor de TLS do Envoy. Para obter mais informações, consulte [Inspector de TLS](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) na documentação do Envoy. Esse filtro avalia se uma conexão está ou não usando TLS inspecionando o primeiro pacote enviado pelo cliente. Com o MySQL e o SMTP, no entanto, o servidor envia o primeiro pacote após a conexão. Para obter mais informações sobre o MySQL, consulte [Initial Handshake](https://dev.mysql.com/doc/internals/en/initial-handshake.html) na documentação do MySQL. Como o servidor envia o primeiro pacote, a inspeção no filtro falha.
**Para contornar esse problema, dependendo da sua versão do Envoy:**
+ Se a versão do App Mesh image Envoy for 1.15.0 ou posterior, não modele serviços externos como **MySQL**, **SMTP**, **MSSQL**, etc. como back-end para o nó virtual da sua aplicação.
+ Se a versão do Envoy na imagem do App Mesh for anterior à 1.15.0, adicione a porta `3306` à lista de valores para o `APPMESH_EGRESS_IGNORED_PORTS` em seus serviços para **MySQL** e como a porta que você está usando para **STMP**.
**Importante**
Embora as portas SMTP padrão sejam `25`, `587` e `465`, você só deve adicionar a porta que está usando ao `APPMESH_EGRESS_IGNORED_PORTS` e não todas as três.
Para obter mais informações, consulte [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) para Kubernetes, [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) para Amazon ECS ou [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) para Amazon EC2.
Se o problema ainda não foi resolvido, você pode nos fornecer detalhes sobre o que está enfrentando ao usar o [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/62) existente ou entrar em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível se conectar a um serviço modelado como um nó virtual TCP ou roteador virtual no App Mesh
**Sintomas**
Seu aplicativo não consegue se conectar a um back-end que usa a configuração do protocolo TCP na definição do App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html).
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte [Roteamento para vários destinos TCP na mesma porta](https://github.com/aws/aws-app-mesh-roadmap/issues/195) ativada. GitHub Atualmente, o App Mesh não permite que vários destinos de back-end modelados como TCP compartilhem a mesma porta devido a restrições nas informações fornecidas ao proxy Envoy na camada 4 da OSI. Para garantir que o tráfego TCP possa ser roteado adequadamente para todos os destinos de back-end, faça o seguinte:
+ Certifique-se de que todos os destinos estejam usando uma porta exclusiva. Se estiver usando um provedor de roteador virtual para o serviço virtual de back-end, poderá alterar a porta do roteador virtual sem alterar a porta nos nós virtuais para os quais ele é roteado. Isso permite que as aplicações abram conexões na porta do roteador virtual enquanto o proxy Envoy continua usando a porta definida no nó virtual.
+ Se o destino modelado como TCP for um servidor MySQL, ou qualquer outro protocolo baseado em TCP no qual o servidor envia os primeiros pacotes após a conexão, consulte [Não é possível conectar-se a um servidor MySQL ou SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp).
Se o problema ainda não foi resolvido, você pode nos fornecer detalhes sobre o que está enfrentando ao usar o [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/195) existente ou entrar em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A conectividade é bem-sucedida em um serviço não listado como back-end de serviço virtual para um nó virtual
**Sintomas**
Sua aplicação é capaz de se conectar e enviar tráfego para um destino que não está especificado como back-end de serviço virtual em seu nó virtual.
**Resolução**
Se as solicitações forem bem-sucedidas em um destino que não tenha sido modelado no App Mesh APIs, a causa mais provável é que o tipo de [filtro de saída](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) da malha tenha sido definido como. `ALLOW_ALL` Quando o filtro de saída estiver definido como `ALLOW_ALL`, uma solicitação de saída da sua aplicação que não corresponda a um destino modelado (back-end) será enviada para o endereço IP de destino definido pela aplicação.
Se quiser proibir o tráfego para destinos não modelados na malha, considere definir o valor do filtro de saída como `DROP_ALL`.
**nota**
A configuração do valor do filtro de saída da malha afeta todos os nós virtuais dentro da malha.
Configurar `egress_filter` como `DROP_ALL` e habilitar o TLS não está disponível para tráfego de saída que não seja para um domínio. AWS
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Algumas solicitações falham com o código de status HTTP `503` quando um serviço virtual tem um provedor de nó virtual
**Sintomas**
Uma parte das solicitações da sua aplicação falha em um back-end de serviço virtual que está usando um provedor de nó virtual em vez de um provedor de roteador virtual. Ao usar um provedor de roteador virtual para o serviço virtual, as solicitações não falham.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte a [política de repetição do provedor de nó virtual para um serviço virtual](https://github.com/aws/aws-app-mesh-roadmap/issues/194) em GitHub. Ao usar um nó virtual como provedor de um serviço virtual, não é possível especificar a política padrão de tentativas que deseja que os clientes do seu serviço virtual usem. Em comparação, os provedores de roteadores virtuais permitem que políticas de tentativas sejam especificadas porque elas são uma propriedade dos recursos da rota subordinada..
Para reduzir as falhas de solicitação aos provedores de nós virtuais, use um provedor de roteador virtual e, em vez disso, especifique uma política de tentativas em suas rotas. Para outras formas de reduzir as falhas de solicitação em seus aplicativos, consulte [Práticas recomendadas do App Mesh](best-practices.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um sistema de arquivos do Amazon EFS
**Sintomas**
Ao configurar uma tarefa do Amazon ECS com um sistema de arquivos do Amazon EFS como volume, a tarefa falha ao iniciar com o seguinte erro.
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Resolução**
Esse é um problema conhecido. Esse erro ocorre porque a conexão do NFS com o Amazon EFS ocorre antes que qualquer contêiner em sua tarefa tenha sido iniciado. Esse tráfego é roteado pela configuração do proxy para o Envoy, que não estará em execução neste momento. Devido à ordem de startup, o cliente NFS falha ao se conectar ao sistema de arquivos do Amazon EFS e a tarefa falha ao ser iniciada. Para resolver o problema, adicione a porta `2049` à lista de valores para a configuração `EgressIgnoredPorts` na configuração de proxy da sua definição de tarefa do Amazon ECS. Para obter mais informações, consulte [Configuração de proxy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A conectividade é bem-sucedida no serviço, mas a solicitação recebida não aparece nos logs de acesso, rastreamentos ou métricas do Envoy
**Sintomas**
Mesmo que a aplicação possa se conectar e enviar solicitações para outra aplicação, você não pode ver as solicitações recebidas nos logs de acesso ou nas informações de rastreamento do proxy Envoy.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte [configuração das regras do iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) em problema no GitHub. O proxy Envoy só intercepta apenas o tráfego de entrada para a porta na qual o nó virtual correspondente está escutando. As solicitações para qualquer outra porta irão ignorar o proxy Envoy e chegar diretamente ao serviço por trás dele. Para permitir que o proxy Envoy intercepte o tráfego de entrada do seu serviço, é preciso configurar seu nó virtual e o serviço para escutar na mesma porta.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Definir as variáveis de ambiente `HTTP_PROXY`/`HTTPS_PROXY` no nível do contêiner não funciona conforme o esperado.
**Sintomas**
Quando HTTP\$1PROXY/HTTPS\$1PROXY é definido como uma variável de ambiente no:
+ No contêiner da aplicação na definição da tarefa com o App Mesh ativado, as solicitações enviadas para o namespace dos serviços do App Mesh receberão respostas de erro `HTTP 500` do sidecar do Envoy.
+ O contêiner Envoy na definição da tarefa com o App Mesh ativado, as solicitações provenientes do sidecar do Envoy não passarão pelo servidor proxy `HTTP`/`HTTPS` e a variável de ambiente não funcionará.
**Resolução**
Para o contêiner da aplicação:
O App Mesh funciona fazendo com que o tráfego em sua tarefa passe pelo proxy Envoy. A configuração `HTTP_PROXY`/`HTTPS_PROXY` substitui esse comportamento configurando o tráfego do contêiner para passar por um proxy externo diferente. O tráfego ainda será interceptado pelo Envoy, mas ele não oferece suporte ao proxy do tráfego de malha usando um proxy externo.
Se quiser fazer o proxy de todo o tráfego que não seja de malha, defina o `NO_PROXY` para incluir o CIDR/namespace, o host local e os endpoints da credencial da malha, como no exemplo a seguir.
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Para o contêiner Envoy:
O Envoy não oferece suporte a um proxy genérico. Não recomendamos definir essas variáveis.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Tempos limite de solicitação upstream mesmo depois de definir o tempo limite para rotas.
**Sintomas**
Tempo limite definido para:
+ As rotas, mas você ainda está recebendo um erro de tempo limite da solicitação upstream.
+ O receptor do nó virtual, o tempo limite e o tempo limite de novas tentativas das rotas, mas ainda assim está recebendo um erro de tempo limite de solicitação upstream.
**Resolução**
Para que as solicitações de alta latência superiores a 15 segundos sejam concluídas com êxito, é preciso especificar um tempo limite no nível da rota e do receptor do nó virtual.
Se você especificar um tempo limite de rota maior que o padrão de 15 segundos, certifique-se de que o tempo limite também seja especificado para o receptor de todos os nós virtuais participantes. No entanto, se você diminuir o tempo limite para um valor menor que o padrão, é opcional atualizar os tempos limite nos nós virtuais. Para obter mais informações sobre as opções ao configurar nós e rotas virtuais, consulte [nós virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) e [rotas virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Se especificou uma **política de tentativa**, a duração especificada para o tempo limite da solicitação deve sempre ser maior ou igual ao *tempo limite de tentativa* multiplicado pelo *máximo de tentativas* que você definiu na **política de tentativas**. Isso permite que a solicitação com todas as novas tentativas seja concluída com êxito. Para obter mais informações, consulte [rotas](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O Envoy responde com uma solicitação HTTP inválida.
**Sintomas**
O Envoy responde com **solicitação HTTP 400 inválida** para todas as solicitações enviadas pelo Network Load Balancer (NLB). Ao verificamos os logs do Envoy, vemos:
+ Logs de depuração:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ Logs de acesso:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Resolução**
A resolução é desativar a versão 2 do protocolo proxy (PPv2) nos atributos do [grupo-alvo](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) do seu NLB.
Atualmente, ele não PPv2 é suportado pelo gateway virtual e pelo nó virtual Envoy, que são executados usando o plano de controle do App Mesh. Se você implantar o NLB usando o controlador de balanceador de AWS carga no Kubernetes, desative PPv2 definindo o seguinte atributo como: `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Consulte [Anotações do controlador balanceador de carga da AWS](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) para obter mais detalhes sobre os atributos de recursos do NLB.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não foi possível configurar o tempo limite corretamente.
**Sintomas**
Sua solicitação atinge o tempo limite em 15 segundos, mesmo depois de configurar o tempo limite no receptor do nó virtual e o tempo limite na rota em direção ao back-end do nó virtual.
**Resolução**
Certifique-se de que o serviço virtual correto esteja incluído na lista de back-end.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).