Base de Conhecimento

Erro 403 Forbidden: o que é e como resolver no seu site

  • erro 403, forbidden, nginx, permissões, vps, tutorial
  • Usuários acharam útil: 0

Entenda o erro 403 Forbidden no Nginx: leia o log, confira o arquivo de índice, as permissões e as regras deny, e saiba o que evitar ao tentar resolver.

Por Redação Eleven Host · @robson.direitodigital · 28 de outubro de 2026 · 7 min de leitura

Arte da Eleven Host: janela de terminal com o título: Erro 403 Forbidden: o que é e como resolver no seu site

Capa da Redação Eleven Host para o guia: Erro 403 Forbidden: o que é e como resolver no seu site Arte: Eleven Host

O erro 403 forbidden significa que o servidor entendeu o pedido e se recusa a entregar a página. Na VPS com Nginx, leia o log de erros e confira três pontos: arquivo de índice, permissões e regras deny.

Este guia é para quem tem um site numa VPS com Nginx e recebeu a tela de 403 ao abrir o endereço. A ordem segue o diagnóstico: o que o erro quer dizer, o que cabe ao visitante, como ler o log e quatro causas para checar. O nome seudominio.com.br é um exemplo. Troque pelo seu.

O que significa o erro 403 Forbidden

Segundo a MDN, o código de resposta de status de erro do cliente HTTP 403 Forbidden indica que o servidor entendeu o pedido, mas se recusa a autorizá-lo. A MDN compara com o 401 e explica que, no 403, a nova autenticação não fará diferença.

Em linguagem simples: o servidor achou o endereço, mas não quer (ou não pode) entregar o conteúdo. É diferente de outros erros que você pode ver no mesmo site:

Resumindo: no 403 o servidor está de pé e respondendo. A recusa pode vir de uma regra, de uma permissão, da falta de um arquivo ou de um plugin.

Se você é visitante ou dono do site

Se você só está visitando o site de outra pessoa, há pouco a fazer do seu lado: confira se digitou o endereço certo e tente de novo mais tarde. A decisão de recusar está no servidor dele.

Se o site é seu e roda numa VPS, o motivo está na configuração ou nas permissões. Os passos abaixo mostram como descobrir qual das causas é a sua.

Passo 1: ler o log de erros do Nginx

O log de erros do Nginx pode mostrar o motivo da recusa. Veja as últimas 50 linhas do log:

sudo tail -n 50 /var/log/nginx/error.log

Duas mensagens que podem aparecer, e o que cada uma indica:

  • directory index of "/var/www/seudominio.com.br/" is forbidden: a pasta não tem arquivo de índice (passo 2).
  • (13: Permission denied): o Nginx não consegue ler o arquivo ou a pasta (passo 3).

Se o log mostrar outra mensagem, leia a linha inteira antes de mexer na configuração. Se não aparecer nada relacionado, o bloqueio pode vir de uma regra de acesso (passo 4) ou de um plugin (passo 5).

Para resolver o 403, não abra tudo. Liberar permissão total ou ligar a listagem de pastas pode fazer o erro sumir, mas expõe arquivos. Ache a causa no log e corrija só o que está errado.

Passo 2: pasta sem arquivo de índice

A diretiva index do Nginx define os arquivos usados como página inicial de uma pasta. Eles são conferidos na ordem, e o padrão é index index.html;.

Se a pasta do site não tem nenhum desses arquivos, o Nginx procura a listagem de pastas, que é feita pelo módulo autoindex. Segundo a documentação do Nginx, ele vem desligado (autoindex off;). Sem índice e com a listagem desligada, a resposta é 403.

Confira o que existe na pasta do site:

ls -la /var/www/seudominio.com.br/

Se o site é em PHP ou WordPress, o bloco server precisa listar o index.php. A linha fica assim, como no guia Instalar WordPress na VPS: passo a passo com Nginx:

index index.php index.html;

Não ligue o autoindex on; para fazer o erro sumir. Isso mostra a lista de arquivos da pasta para quem visitar o endereço. O caminho certo é ter o arquivo de índice no lugar e apontado na diretiva index.

Passo 3: permissões de arquivos e pastas

O Nginx precisa ler o arquivo e também atravessar cada pasta do caminho até ele. Uma pasta no meio do caminho sem permissão já pode causar o 403 no arquivo lá no fim.

O comando namei segue o caminho e, com a opção -l, mostra as permissões de cada parte, no estilo do ls:

namei -l /var/www/seudominio.com.br/index.php

Olhe cada linha da saída: dono, grupo e permissões de cada pasta do caminho. Procure uma pasta ou o arquivo que o usuário do Nginx não consiga ler.

A documentação do WordPress recomenda pastas com permissão 755 ou 750, arquivos com 644 ou 640 e o wp-config.php com 440 ou 400. Para ajustar um site inteiro a esses valores, rode os dois comandos abaixo. Eles mudam as permissões de tudo dentro da pasta e deixam também o wp-config.php em 644. Confirme o caminho antes de executar:

sudo find /var/www/seudominio.com.br -type d -exec chmod 755 {} \;

sudo find /var/www/seudominio.com.br -type f -exec chmod 644 {} \;

Não use 777. A documentação do WordPress alerta que essa permissão deixa os arquivos acessíveis e modificáveis por outros usuários e processos, e orienta: quando vir 777, pergunte por que ele é necessário.

Quer um servidor para hospedar o seu site? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Ver planos de VPS

Passo 4: regra deny esquecida

As diretivas allow e deny do Nginx são conferidas em sequência, até a primeira que casar com o visitante. O deny all; nega quem sobrou.

Por isso, um deny esquecido dá 403 para quem está de fora. Um exemplo: uma área do site restrita a um IP. Procure as regras nos sites ativos:

sudo grep -rn "deny" /etc/nginx/sites-enabled/

Cada linha da saída mostra o arquivo e o número da linha. Abra o arquivo, veja em qual location ou bloco a regra está e confira se ela deveria mesmo valer para aquele endereço.

Passo 5: plugin de segurança ou firewall de aplicação

Se o log do Nginx não aponta nada, o bloqueio pode vir de outra camada: um plugin de segurança do seu site ou um firewall de aplicação que barra o IP do visitante. Nesse caso, a recusa vem da regra dessa camada, e não do Nginx.

Para testar, desative um por vez e recarregue a página. Se o 403 sumir, você achou o responsável. Aí revise as regras dele e reative-o, em vez de deixá-lo desligado. Se o site inteiro saiu do ar e você precisa de um roteiro mais amplo, veja Site fora do ar: o que fazer, passo a passo.

Testar e recarregar o Nginx

Depois de mexer na configuração do Nginx, teste a sintaxe antes de aplicar:

sudo nginx -t

Se o teste apontar erro, não recarregue: corrija a linha indicada. Estando tudo certo, recarregue:

sudo systemctl reload nginx

Depois abra o endereço do site e confira se o 403 saiu. Se continuar, volte ao log do passo 1: a mensagem nova pode apontar outra causa.

Checklist do 403

  • Li o error.log do Nginx e anotei a mensagem.
  • Conferi se a pasta do site tem o arquivo de índice (index.php ou index.html).
  • Conferi a diretiva index no bloco server.
  • Rodei o namei -l e olhei as permissões de cada pasta do caminho.
  • Ajustei para 755 nas pastas e 644 nos arquivos, sem usar 777.
  • Procurei regras deny com o grep.
  • Desativei um plugin de segurança por vez, para testar.
  • Rodei nginx -t antes de recarregar.

Já pensou no endereço do seu site? Busque o nome e registre o seu domínio na Eleven Host. Registrar domínio

Perguntas frequentes

O erro 403 Forbidden é problema do meu navegador?

Segundo a MDN, o 403 indica que o servidor entendeu o pedido e se recusa a autorizá-lo. Como a recusa vem do servidor, o que você tem a fazer do seu lado é conferir o endereço e tentar mais tarde.

Qual a diferença entre o 403 e o 404?

No 404, o servidor não achou o que foi pedido. No 403, ele entendeu o pedido e recusou entregar.

Posso ligar o autoindex para resolver o 403?

Não é o caminho. A listagem de pastas, que o autoindex on; liga, mostra os arquivos da pasta a quem visitar o endereço. Coloque o arquivo de índice no lugar certo.

Posso usar a permissão 777 para o erro sumir?

Não. A documentação do WordPress alerta que o 777 deixa os arquivos acessíveis e modificáveis por outros usuários e processos. Use 755 nas pastas e 644 nos arquivos.

Esta resposta lhe foi útil?

Artigos Relacionados