Estamos executando n8n 2.26.4 auto-hospedado no Elestio e não conseguimos conectar Claude.ai à nossa instância via MCP. O MCP em nível de instância está ativado e o OAuth/token de acesso está configurado.
Tentamos tanto o conector de parceria oficial do n8n no Claude.ai quanto um conector personalizado usando a URL direta do servidor MCP (formato: https://your-instance.vm.elestio.app/mcp-server/http). Ambos falham com o mesmo erro no lado do Claude:
„A autorização com o servidor MCP falhou. Você pode verificar suas credenciais e permissões.‟
Interessantemente, no lado do n8n, a guia Connected Clients realmente mostra novas entradas do Claude aparecendo cada vez que tentamos conectar, então o n8n está recebendo a tentativa de conexão. O handshake de autenticação simplesmente não está sendo concluído com sucesso no lado do Claude.
Códigos de referência das três tentativas falhadas:
- ofid_ccb9a1fd230c7285
- ofid_757ab36960e137e7
- ofid_a02cf908ec28723f
Alguém pode nos ajudar a identificar o que está bloqueando a conclusão da autorização?
1 curtida
Essas linhas Connected Clients são úteis: Claude está alcançando n8n, então a próxima divisão é descoberta de URL versus troca de token. Tente uma reconexão limpa com a URL MCP direta, depois verifique o log n8n para esse mesmo ofid_...; se falhar durante a troca de token, cole essa linha de log com nomes de host/secrets removidos e o tipo de credencial OAuth que você usou.
1 curtida
Atualização: Analisamos os logs mais a fundo e encontramos a causa raiz.
Todas as tentativas de conexão mostram:
ValidationError: Um 'request.ip' inválido foi detectado
seguido imediatamente por “Deleting OAuth client” e “OAuth client deleted successfully”. A sessão OAuth está sendo criada e depois imediatamente encerrada porque o rate limiter do n8n está rejeitando o IP malformado vindo do nginx reverse proxy na frente da nossa instância.
Definimos N8N_TRUST_PROXY=true e N8N_PROXY_HOPS=1, mas o problema está na camada do nginx. O nginx está encaminhando headers X-Forwarded-For mas está faltando as diretivas real_ip_header e set_real_ip_from, então o n8n recebe um IP malformado e encerra a sessão OAuth antes que a troca de token possa ser concluída.
Escalamos para a Elestio (nosso provedor de hospedagem) para adicionar as diretivas de real_ip do nginx. Há algo que possamos fazer no lado do n8n para contornar ou desabilitar a validação de IP do rate limiter como uma solução temporária enquanto aguardamos?
Uma coisa que vale a pena tentar enquanto aguarda a Elestio: defina N8N_PROXY_HOPS=0 temporariamente. Isso informa ao n8n que ele não está atrás de nenhum proxy, então ele para de tentar analisar os cabeçalhos X-Forwarded-For inteiramente e usa o IP da conexão bruta em vez disso - o que contorna a validação de IP malformado que está prejudicando o handshake do OAuth. A desvantagem é que a limitação de taxa será aplicada ao IP do proxy em vez dos IPs de clientes reais, mas para um servidor MCP isso geralmente é aceitável. Quando a Elestio aplicar as diretivas nginx real_ip_header e set_real_ip_from, volte a N8N_PROXY_HOPS=1 para que a limitação de taxa funcione corretamente novamente.
1 curtida
Meesam, trate a ideia N8N_PROXY_HOPS=0 acima como um teste de isolamento temporário, não como a solução. Ela faz o n8n aplicar rate-limit contra o IP do proxy, então mantenha-a por pouco tempo e volte assim que o Elestio configurar a cadeia real de IP.
Não desative o limitador em si no n8n para isso. A solução durável ainda está upstream: o nginx precisa passar uma cadeia válida de IP do cliente confiável antes de o caminho OAuth/rate-limit se comportar normalmente.
1 curtida
Atualização: Progresso realizado. O loop de exclusão do OAuth foi corrigido. Os logs agora mostram “Consent approved” e “Refresh token rotated and new access token issued” a cada tentativa, então o fluxo OAuth está sendo concluído com sucesso no lado do n8n. Porém Claude.ai ainda mostra “Authorization with the MCP server failed”. A falha agora está ocorrendo depois que o OAuth é concluído, durante a inicialização da sessão MCP. Alguma ideia do que poderia causar a falha da sessão MCP após um handshake OAuth bem-sucedido?
Meesam, se n8n agora mostra consentimento aprovado e rotação de token, pare de procurar pelo caminho de proxy/IP para esta parte. A próxima verificação é se Claude está alcançando o endpoint do MCP após OAuth: na mesma tentativa, os logs do n8n mostram uma requisição para /mcp-server/http após a linha do token, ou fica silencioso?
Se ficar silencioso, o conector provavelmente está falhando antes que session init chegue ao n8n. Se uma requisição chegar, cole a primeira linha de erro da MCP-session com nomes de host/tokens removidos; o código de status lá importa mais do que as linhas de OAuth agora.
Verifiquei os logs imediatamente após uma tentativa de conexão. Depois de „Consentimento aprovado
Isso reduz muito: se n8n fica silencioso após a rotação do token, o passo que falhou provavelmente não é mais n8n aceitando o resultado do OAuth. Claude consegue passar por isso, mas não inicia a solicitação de sessão MCP.
A próxima pista é a URL MCP do lado do cliente que Claude salvou. É exatamente a URL pública https://.../mcp-server/http, sem barra final/reescrita de caminho do Elestio? Se essa URL é exata e n8n ainda não vê nada após a rotação do token, isso provavelmente está no lado do cliente MCP remoto do Claude, em vez de uma configuração de fluxo de trabalho do n8n.
Tentei a abordagem de chave de API incorporando-a na URL como parâmetro de consulta. Ainda estou recebendo „A autorização com o servidor MCP falhou
A abordagem com parâmetro de consulta não funcionará - o cliente MCP do Claude.ai envia o token como `Authorization: Bearer
<key
` no cabeçalho da requisição, não como um parâmetro de URL. O problema é quase certamente que o nginx do Elestio está removendo o cabeçalho Authorization antes dele chegar ao n8n.
Na sua configuração de nginx do Elestio, certifique-se de que isto está presente no bloco de localização que manipula o MCP:
proxy_set_header Authorization $http_authorization;
Sem isso, o nginx passa cookies e cabeçalhos customizados, mas remove o cabeçalho Authorization por padrão, então o servidor MCP do n8n nunca vê o token e rejeita a conexão. Uma vez que o repasse desse cabeçalho esteja em vigor, use a chave da API do n8n diretamente no conector do Claude - sem necessidade de incorporação na URL.
1 curtida
Atualização: Testei o endpoint MCP diretamente com curl. O endpoint anuncia autenticação Bearer via WWW-Authenticate: Bearer realm="n8n MCP Server", mas retorna "Missing Bearer prefix" mesmo ao enviar um header Authorization: Bearer <token> válido. O token está chegando ao n8n (confirmado que nginx passa headers de Authorization). Usando tanto o token de acesso MCP quanto a chave de API n8n, ambos retornam HTTP 401. Existe um formato de token específico ou um endpoint que o servidor MCP espera para autenticação Bearer direta na versão 2.26.4?
Resolvido - aqui está o que realmente funcionou para quem está no Elestio:
A causa raiz era a configuração nginx do Elestio estar perdendo as diretivas de proxy específicas do MCP. Mesmo que o nginx estivesse passando headers de Authorization para outras rotas, o bloco de localização que manipulava o endpoint MCP do n8n (/mcp-server/http) não estava configurado corretamente para passar pelos headers e lidar com a inicialização da sessão MCP.
A solução foi o Elestio atualizar a configuração nginx do serviço n8n com as diretivas de proxy corretas para o endpoint MCP. Não conseguimos as linhas exatas que foram alteradas, mas o sintoma era:
- OAuth completou com sucesso (consentimento aprovado, tokens emitidos nos logs do n8n)
- Claude nunca acessou
/mcp-server/http após a troca de token, os logs ficaram silenciosos
- curl direto para
/mcp-server/http com um Bearer token retornou 401 com o erro contraditório “Missing Bearer prefix” mesmo com o prefixo Bearer presente
- Depois que o Elestio atualizou a configuração MCP do nginx, a conexão funcionou imediatamente
Outras coisas que corrigimos no caminho que não eram a causa raiz mas eram problemas reais:
- n8n estava na versão 1.121.3, atualizado para 2.26.4 (necessário para suporte estável de MCP)
- Adicionado
N8N_TRUST_PROXY: "true" ao docker-compose.yml (boa prática atrás de um proxy reverso)
- O
N8N_PROXY_HOPS=1 já estava definido corretamente, não altere isso
Se você está no Elestio e enfrentando a mesma situação, abra um ticket de suporte e peça a eles para atualizar a configuração MCP do nginx para seu serviço n8n. Eles consertaram rapidamente assim que fornecemos o erro específico.
1 curtida
