Django 사이트에 들어온 WordPress 경로 요청

방문자 통계를 정리하던 중 /wp-admin/, /xmlrpc.php, /info.php처럼 이 사이트에서 사용하지 않는 경로 요청이 보였습니다. 원문에서는 이런 요청을 Nginx에서 먼저 처리하는 방법을 소개했습니다. 다만 경로 하나만으로 요청자의 의도나 실제 침해 성공 여부를 확정할 수는 없습니다. 이 글은 존재하지 않는 경로가 Django까지 전달되는 일을 줄이는 설정 검토 기록입니다.

2026년 9월 22일 저장소의 docker/prod/nginx.conf에는 원문에 제시한 WordPress·PHP 차단 규칙이 없습니다. NAS에서 실제 로드한 설정을 새로 읽은 것도 아니므로, 아래 내용은 추가를 검토할 예제이며 현재 차단 완료 상태라는 뜻이 아닙니다.

광범위한 정규식보다 경로 범위를 먼저 정한다

원문은 wp-admin으로 시작하는 경로를 넓게 매칭했습니다. 그러면 /wp-admin-guide/ 같은 글 주소까지 함께 잡을 수 있습니다. 또 모든 점으로 시작하는 경로를 차단하면 인증서 검증 등에 쓰는 /.well-known/과 충돌할 수 있습니다. “Django니까 PHP나 점이 들어간 URL은 모두 차단”이라는 판단보다 실제 사용 경로를 대조해야 합니다.

다음은 기존 대상 server 블록 안에서 검토할 최소 예제입니다. 사이트의 정상 경로·정적 파일 설정을 포함한 전체 설정은 아닙니다.

location = /wp-admin {
    return 404;
}
location ^~ /wp-admin/ {
    return 404;
}
location = /xmlrpc.php {
    return 404;
}

정확히 /wp-admin과 그 하위 디렉터리, 정확한 /xmlrpc.php만 대상으로 삼았습니다. 대소문자 변형이나 다른 WordPress 경로 전체를 포괄하지 않습니다. 실제 로그에서 필요한 범위를 추가하되 정상 URL도 함께 확인합니다. 기존 error_page, 다른 location, 앞단 프록시에 따라 최종 응답 처리가 달라질 수 있습니다.

정확 일치와 접두 경로의 우선순위는 Nginx location 문서를 기준으로 검토합니다. 444는 Nginx의 연결 종료 동작이며 일반적인 HTTP 오류 페이지처럼 응답을 주지 않습니다. 이 예제는 응답 코드를 확인하기 쉬운 404를 사용합니다.

문법 검사와 동작 검사는 다른 단계다

운영 Compose의 Nginx 컨테이너 이름은 myapp_nginx이고, 설정 파일은 /etc/nginx/nginx.conf로 연결됩니다. 다음은 기존 컨테이너의 설정 검사이며 재시작 명령이 아닙니다.

docker exec myapp_nginx nginx -t

검사가 성공해도 의도한 요청이 해당 규칙에 들어오는지, 다른 도메인과 정상 경로가 보존되는지는 확인되지 않습니다. 적용을 승인한 뒤에만 설정을 다시 읽게 하고, 다음처럼 차단 대상과 정상 대조 경로를 함께 검사합니다. Nginx 설정 재적용 설명은 문법 검증과 새 worker 전환 과정을 설명합니다.

시험 요청 위 예제에서 의도한 처리
/wp-admin 이 규칙에서 404
/wp-admin/ 이 규칙에서 404
/wp-admin/options.php 접두 규칙에서 404
/xmlrpc.php?test=1 정확한 URI 경로 규칙에서 404
/wp-admin-guide/ 이 차단 규칙에 포함되지 않음
/.well-known/example 이 차단 규칙에 포함되지 않음

마지막 두 경로가 반드시 200이라는 뜻은 아닙니다. 다른 설정이나 Django에서 404가 날 수 있으므로 404라는 결과만으로 Nginx 차단 성공을 증명할 수 없습니다. 테스트 요청 시각, 해당 Nginx access log, web upstream 로그를 대조해 처리 위치를 확인합니다. 로그에서 IP·쿠키·토큰이 보이면 공개 기록에 그대로 옮기지 않습니다.

통계 필터와 요청 차단은 별도로 본다

Nginx에서 요청을 끝내면 그 요청은 Django 미들웨어의 방문자 집계에 들어오지 않을 수 있습니다. 그러나 이미 저장한 과거 통계가 자동으로 정리되지는 않습니다. 통계가 줄었다는 사실만으로 서버 처리량이 개선됐다고 주장할 수도 없습니다. 전후 기간, 응답 수, upstream 전달량과 자원 사용을 비교해야 하는 별도 측정입니다.

이 글에서는 운영 차단 규칙을 새로 배포하거나 성능 향상 수치를 측정하지 않았습니다. 저장소 규칙과 실제 NAS 설정 대조, 정상 경로 회귀 검사, 적용 후 로그 확인을 마친 뒤 결과를 기록할 수 있습니다. 관련 점검 명령은 PuTTY에서 실행 위치를 구분하는 방법을 참고하세요.