리눅스 서버 403 Forbidden 뜰 때 nginx 설정과 디렉터리 권한 확인하는 법

리눅스 서버에서 403 Forbidden 오류가 발생했을 때 파일 권한, nginx location 설정, 접근 제한 정책, 웹서버 로그를 확인하는 방법을 설명하는 대표 이미지

리눅스 서버에서 웹페이지 접속 중 403 Forbidden 오류가 뜨면 웹서버가 죽은 건지, 방화벽 문제인지부터 떠올리기 쉽습니다. 하지만 서버 운영 중 만나는 403 오류는 nginx나 Apache 같은 웹서버가 요청은 받았지만, 파일 권한, 디렉터리 권한, location 설정, allow/deny 정책, index 파일 누락 때문에 접근을 막는 경우가 많습니다. 이번 글에서는 403 Forbidden 원인을 확인할 때 바로 재기동하거나 chmod부터 하지 않고, 어떤 순서로 보면 안전한지 정리해보겠습니다.

403 Forbidden은 무슨 뜻일까?

403 Forbidden은 말 그대로 접근이 금지되었다는 뜻입니다.

404가 “요청한 대상을 찾지 못함”에 가깝다면,
403은 “요청한 대상이 있거나 경로는 맞는 것 같은데 접근 권한이 없음”에 가깝습니다.

예를 들면 이런 상황입니다.

파일은 있는데 웹서버 계정이 읽을 권한이 없음
디렉터리 실행 권한이 없음
index.html이 없고 디렉터리 목록 노출도 막혀 있음
nginx allow/deny 설정에 걸림
Apache Require 설정에 걸림
SELinux 정책에 막힘

 

그래서 403이 떴다고 바로 서버가 죽었다고 보면 안 됩니다.
오히려 웹서버는 살아 있고, 요청도 받았고, 그 다음 단계에서 “이건 보여줄 수 없음”이라고 응답하는 상황일 수 있습니다.

초보 운영자가 하기 쉬운 실수

403을 보면 급한 마음에 이런 명령어를 떠올리기 쉽습니다.

 

systemctl restart nginx
chmod -R 777 /var/www/html

 

하지만 운영 서버에서 chmod -R 777 같은 명령어는 정말 조심해야 합니다.
권한을 너무 넓게 열어버리면 당장은 접속이 될 수 있어도, 보안상 더 큰 문제가 생길 수 있습니다.

403은 재기동보다 먼저 누가, 어디에, 어떤 권한으로 접근하려고 했는지를 확인해야 합니다.

운영에서는 “일단 열어보자”보다
필요한 권한만 정확히 주는 것이 더 안전합니다.

404 오류는 요청한 경로를 찾지 못하는 상황에 가깝고, 403 Forbidden은 경로는 맞지만 접근이 막힌 상황에 가깝습니다. 두 상태코드를 헷갈리기 쉽다면 이전 글인 “리눅스 서버 404 오류가 날 때 서버 죽은 줄 알기 전 먼저 확인할 것”도 함께 보면 좋습니다.

1단계. curl로 403 응답이 맞는지 확인하기

먼저 브라우저 화면만 보지 말고 curl로 HTTP 상태코드를 확인합니다.

 

curl -I http://example.com/admin

 

예시 결과입니다.

HTTP/1.1 403 Forbidden
Server: nginx
Content-Type: text/html

 

여기서 볼 것은 두 가지입니다.

1. 실제 상태코드가 403인지
2. 응답을 준 서버가 nginx인지 Apache인지 애플리케이션인지

 

Server: nginx가 보인다면 nginx가 요청을 받고 403을 반환한 상황일 수 있습니다.
이 경우 웹서버 프로세스 자체가 죽었다기보다는, 웹서버 설정이나 파일 접근 권한 문제를 먼저 봐야 합니다.

2단계. 어떤 경로에서 403이 나는지 확인하기

403은 전체 사이트에서 날 수도 있고, 특정 경로에서만 날 수도 있습니다.

예를 들어 아래처럼 나뉠 수 있습니다.

 

curl -I http://example.com/
curl -I http://example.com/admin
curl -I http://example.com/static/app.js
curl -I http://example.com/upload/

 

확인 결과가 이렇게 다를 수 있습니다.

/                  → 200 OK
/admin             → 403 Forbidden
/static/app.js     → 200 OK
/upload/           → 403 Forbidden

 

이런 경우 서버 전체 장애라기보다 /admin 또는 /upload/ 경로에 걸린 설정, 권한, index 파일 문제일 가능성이 큽니다.

초보 운영자 입장에서는 “사이트가 안 된다”로 보이지만, 실제로는 특정 경로만 막혀 있는 경우가 많습니다.

3단계. nginx location 설정 확인하기

nginx를 사용 중이라면 location 설정을 확인합니다.

 

grep -R "location" /etc/nginx/
grep -R "deny" /etc/nginx/
grep -R "allow" /etc/nginx/

 

예를 들어 이런 설정이 있을 수 있습니다.

 

location /admin {
    deny all;
}

 

이 경우 /admin 경로는 누구에게도 열리지 않습니다.

또는 특정 IP만 허용하는 설정일 수도 있습니다.

 

location /admin {
    allow 192.0.2.10;
    deny all;
}

 

이 설정에서는 192.0.2.10에서 온 요청만 허용되고, 나머지는 403이 날 수 있습니다.

운영 서버에서는 이 설정이 의도된 보안 정책인지, 최근에 변경된 설정인지 확인해야 합니다.
무작정 deny all을 지우면 관리자 페이지나 내부 경로가 외부에 노출될 수 있습니다.

4단계. root 경로와 index 파일 확인하기

403은 index 파일이 없을 때도 발생할 수 있습니다.

nginx 설정이 이런 식이라고 가정해보겠습니다.

 

location / {
    root /var/www/html;
    index index.html;
}

 

이 경우 웹서버는 /var/www/html/index.html 파일을 찾습니다.

서버에서 실제 파일이 있는지 확인합니다.

 

ls -l /var/www/html
ls -l /var/www/html/index.html

 

만약 디렉터리에는 접근했지만 index 파일이 없고, 디렉터리 목록 노출도 막혀 있다면 403이 발생할 수 있습니다.

예를 들어 이런 상황입니다.

/var/www/html/ 디렉터리는 있음
index.html 파일은 없음
autoindex 설정은 꺼져 있음

 

이때는 서버가 죽은 게 아니라, 보여줄 기본 파일이 없는 상태일 수 있습니다.

5단계. 파일 권한 확인하기

403에서 가장 자주 보는 부분이 파일 권한입니다.

정적 파일이 있는 경로를 확인합니다.

 

ls -l /var/www/html/index.html

 

예시 결과입니다.

 

-rw------- 1 root root 2048 Jul  4 10:00 /var/www/html/index.html

 

이 파일은 소유자인 root만 읽을 수 있습니다.
nginx가 nginx 또는 www-data 같은 별도 계정으로 실행 중이라면 이 파일을 읽지 못해 403이 날 수 있습니다.

웹서버 프로세스 계정도 확인합니다.

 

ps -ef | grep nginx

 

예시입니다.

 

nginx     12345  1234  0 10:00 ?  00:00:00 nginx: worker process

 

이 경우 nginx worker process는 nginx 계정으로 동작하고 있습니다.
그러면 해당 계정이 파일을 읽을 수 있는 권한이 있는지 봐야 합니다.

보통 정적 파일은 최소한 웹서버 계정이 읽을 수 있어야 합니다.

파일: 읽기 권한 필요
디렉터리: 접근을 위한 실행 권한 필요

 

여기서 중요한 점은 디렉터리 권한입니다.
파일 권한만 맞아도 상위 디렉터리에 들어갈 권한이 없으면 403이 날 수 있습니다.

6단계. 디렉터리 권한도 같이 확인하기

파일 권한만 보고 끝내면 놓칠 수 있습니다.
웹서버는 파일까지 도달하기 위해 상위 디렉터리를 지나가야 합니다.

 

namei -l /var/www/html/index.html

 

예시 결과입니다.

 

f: /var/www/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwx------ root root html
-rw-r--r-- root root index.html

 

여기서 /var/www/html 디렉터리가 drwx------라면 root만 접근할 수 있습니다.
파일 자체가 rw-r--r--여도 웹서버 계정은 디렉터리에 들어가지 못할 수 있습니다.

403을 볼 때는 파일 하나만 보지 말고, 경로 전체 권한을 보는 습관이 필요합니다.

7단계. Apache라면 Require 설정 확인하기

Apache 환경에서는 Require 설정 때문에 403이 발생할 수 있습니다.

설정 파일에서 관련 항목을 확인합니다.

 

grep -R "Require" /etc/httpd/
grep -R "Directory" /etc/httpd/

 

Ubuntu 계열이라면 경로가 다를 수 있습니다.

 

grep -R "Require" /etc/apache2/
grep -R "Directory" /etc/apache2/

 

예시 설정입니다.

 

<Directory "/var/www/html/admin">
    Require ip 192.0.2.10
</Directory>

 

이 경우 특정 IP만 접근할 수 있고, 다른 IP에서는 403이 발생할 수 있습니다.

또는 아래처럼 전체 접근이 막혀 있을 수도 있습니다.

 

<Directory "/var/www/html">
    Require all denied
</Directory>

 

이 설정을 수정할 때도 조심해야 합니다.
관리자 경로나 내부 파일 경로를 외부에 열어버릴 수 있기 때문입니다.

8단계. SELinux가 막고 있는지 확인하기

CentOS, Rocky Linux, RHEL 계열에서는 SELinux 때문에 403이 날 수도 있습니다.

먼저 상태를 확인합니다.

 

getenforce

 

결과가 Enforcing이면 SELinux 정책이 적용 중입니다.

 

Enforcing

 

이 경우 파일 권한이 맞아도 SELinux 컨텍스트가 맞지 않으면 웹서버가 파일을 읽지 못할 수 있습니다.

컨텍스트 확인 예시입니다.

 

ls -Z /var/www/html

 

정적 웹 파일이라면 보통 웹서버가 읽을 수 있는 컨텍스트가 필요합니다.
운영 서버에서는 SELinux를 무작정 끄기보다, 어떤 정책에 막혔는지 로그를 먼저 확인하는 것이 안전합니다.

 

ausearch -m avc -ts recent

 

또는 환경에 따라 audit 로그를 확인할 수 있습니다.

 

grep denied /var/log/audit/audit.log | tail -n 20

 

주의할 점은 SELinux를 바로 끄는 방식입니다.

 

setenforce 0

 

이 명령어는 일시적으로 SELinux를 Permissive로 바꾸는 조치입니다.
운영 서버에서는 보안 정책에 영향을 줄 수 있으므로, 테스트 목적이 아니라면 신중하게 판단해야 합니다.

9단계. nginx access.log와 error.log 확인하기

로그는 403 원인을 좁히는 데 중요합니다.

 

tail -n 100 /var/log/nginx/access.log
tail -n 100 /var/log/nginx/error.log

 

access log에서는 어떤 경로가 403인지 확인합니다.

192.0.2.10 - - [04/Jul/2026:10:30:00 +0900] "GET /admin HTTP/1.1" 403 153 "-" "Mozilla/5.0"

 

error log에서는 권한 문제 메시지가 보일 수 있습니다.

open() "/var/www/html/admin/index.html" failed (13: Permission denied)

 

이런 메시지가 보이면 파일 또는 디렉터리 권한 문제를 의심할 수 있습니다.

또 다른 예시는 디렉터리 index 문제입니다.

directory index of "/var/www/html/upload/" is forbidden

 

이 경우 /upload/ 디렉터리에 index 파일이 없고, 디렉터리 목록 표시도 막혀 있어서 403이 발생했을 가능성이 있습니다.

10단계. 최근 변경사항 확인하기

403은 설정 변경이나 배포 이후에 자주 발생합니다.

최근에 이런 작업이 있었는지 확인합니다.

정적 파일 배포
nginx location 수정
Apache Directory 설정 변경
파일 소유자 변경
chmod 또는 chown 작업
SELinux 컨텍스트 변경
방화벽 또는 접근 허용 IP 변경
관리자 경로 접근 정책 변경

 

장애 대응에서는 “지금 뭘 봐야 하지?”도 중요하지만,
“언제부터 발생했지?”가 꽤 큰 단서가 됩니다.

403이 특정 시점 이후 발생했다면, 그 시간대의 배포와 설정 변경을 같이 봐야 합니다.

운영 서버에서 조심할 점

403이 났다고 바로 아래처럼 조치하는 건 위험합니다.

 

chmod -R 777 /var/www/html
chown -R nginx:nginx /var/www/html
systemctl restart nginx
setenforce 0

 

이 명령어들이 항상 틀렸다는 뜻은 아닙니다.
다만 원인을 모른 채 실행하면 권한이 과하게 열리거나, 보안 정책이 약해지거나, 정상 서비스에 영향이 생길 수 있습니다.

운영에서는 이렇게 가는 게 안전합니다.

1. 어느 경로에서 403이 나는지 확인
2. 웹서버 설정 확인
3. 파일과 디렉터리 권한 확인
4. 로그에서 Permission denied 확인
5. SELinux 또는 접근 제한 정책 확인
6. 영향 범위 확인 후 필요한 조치만 적용

 

특히 권한 조정은 “넓게 열기”가 아니라
필요한 대상에게 필요한 권한만 주기가 기준입니다.

정리하면

403 Forbidden은 서버가 죽었다는 뜻이 아닐 수 있습니다.
오히려 서버는 살아 있고, 요청도 받았지만, 어떤 이유로 접근을 막는 상황일 가능성이 큽니다.

확인 순서는 이렇게 잡을 수 있습니다.

1. curl -I 로 403 상태코드 확인
2. 어떤 URL 경로에서 403이 나는지 확인
3. nginx location / allow / deny 설정 확인
4. root 경로와 index 파일 확인
5. 파일 권한 확인
6. 디렉터리 권한 확인
7. Apache라면 Require 설정 확인
8. SELinux 로그 확인
9. access.log / error.log 확인
10. 최근 변경사항 확인

 

403 Forbidden은 서버가 죽었다는 뜻이라기보다, 요청은 도착했지만 접근이 허용되지 않았다는 의미에 가깝습니다.

그래서 403이 보인다고 바로 서버를 재기동하거나 권한을 크게 열기보다, 어떤 계정이 어떤 파일이나 경로에 접근하지 못하는지부터 확인하는 것이 좋습니다.

파일 권한, 디렉터리 실행 권한, nginx location 설정, 접근 제한 정책, SELinux나 보안 설정까지 나눠서 보면 원인을 더 안전하게 좁힐 수 있습니다.

HTTP 오류 코드별 확인 순서를 한 번에 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/63

리눅스 서버 HTTP 응답 코드별 확인 순서 정리, 에러 코드만 봐도 방향이 보입니다

 

웹 장애 상황을 보고할 때 HTTP 코드를 어떻게 정리하면 좋은지는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/64

리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드