500 내부 서버 오류

이 오류의 의미와 확인 방법

• 브라우저에 빈 페이지, 일반적인 500 내부 서버 오류 페이지 또는 사이트 브랜드가 적용된 오류 페이지가 표시됩니다.
• 코드 편집, 플러그인 또는 테마 설치, 업데이트, 배포 또는 구성 변경 후 정상적으로 작동하던 페이지가 실패합니다.
• 사이트의 나머지 부분은 이용 가능하지만 특정 URL, 양식, 관리자 화면 또는 사이트 기능만 실패합니다.
• PHP, 애플리케이션 또는 웹 서버 로그에 동일한 시간대의 치명적 오류, 구문 오류, 권한 문제, 종속성 누락 또는 리소스 제한 초과가 기록됩니다.
• 요청을 반복해도 동일한 500 응답이 반환됩니다. 다만 리소스 제한이나 애플리케이션 종속성이 관련된 경우 간헐적인 오류가 발생할 수도 있습니다.

가능성이 높은 순서의 주요 원인

1. 애플리케이션 코드, 플러그인, 테마 또는 모듈 오류 — 구문 오류, 치명적 오류, 호환되지 않는 업데이트 또는 처리되지 않은 조건으로 인해 요청이 완료되지 않을 수 있습니다.
2. 잘못된 Apache 구성 — .htaccess의 형식이 잘못되었거나 지원되지 않는 지시어, 또는 비활성화된 모듈이 필요한 규칙으로 인해 500 응답이 발생할 수 있습니다. .htaccess는 Apache 기반 설정에 적용되며 모든 웹 서버에 적용되는 것은 아닙니다.
3. 잘못된 파일 또는 디렉터리 권한이나 소유권 — 수동 업로드, 마이그레이션 및 배포 과정에서 웹 프로세스가 필요한 파일을 읽지 못하는 상태가 될 수 있습니다.
4. PHP 메모리 또는 실행 시간 고갈 — 대규모 가져오기, 비용이 큰 쿼리 또는 리소스를 많이 사용하는 확장 기능이 구성된 제한을 초과할 수 있으며, 일부 환경에서는 이때 500 오류를 반환합니다.
5. 배포 구성 또는 종속성 누락 — 변경된 데이터베이스 자격 증명, 누락된 환경 변수, 사용할 수 없는 패키지 또는 호환되지 않는 런타임으로 인해 애플리케이션이 중단될 수 있습니다.
6. 불완전하거나 손상된 애플리케이션 또는 CMS 파일 — 업데이트가 중단되면 필요한 코어 파일이 누락되거나 손상될 수 있습니다.

해결 방법

1. 범위와 발생 시간을 확인하세요

500을 반환하는 정확한 URL을 다시 로드하고 시간과 시간대를 기록하세요. 사이트 전체가 실패하는지, 아니면 특정 경로, 양식, 관리자 화면, 플러그인 기능 또는 요청 유형만 실패하는지 확인하세요. 특정 기능만 실패한다면 해당 기능의 최근 코드와 종속성이 원인일 가능성이 높고, 사이트 전체의 실패라면 서버 구성, 배포 또는 코어 파일 문제일 가능성이 더 높습니다.

2. 먼저 관련 로그를 확인하세요

호스트에서 이용할 수 있는 PHP error_log, 웹 서버 오류 로그 및 애플리케이션 또는 CMS 로그를 검토하세요. 일반적인 위치로는 Apache의 /var/log/apache2/error.log와 Nginx의 /var/log/nginx/error.log가 있지만 호스팅 환경에 따라 경로가 다릅니다. 항목을 오류 발생 시간과 대조하고 파일, 줄 번호, 예외, upstream 메시지 또는 구성 지시어를 기록하세요. 브라우저에 표시되는 일반적인 오류 페이지만으로는 원인을 확인할 수 없습니다.

3. 최근 코드 또는 확장 기능 변경을 격리하세요

로그에서 파일, 플러그인, 테마, 모듈 또는 배포 변경을 지목한다면 테스트 가능한 환경에서 해당 변경을 되돌리거나 지정된 구성 요소를 비활성화하세요. CMS에서는 관리자 화면을 사용할 수 있을 때 해당 화면을 이용하세요. 관리자 화면에 접근할 수 없다면 SFTP 또는 호스팅 파일 관리자를 사용해 관련 구성 요소 디렉터리의 이름을 변경할 수 있습니다. 한 번에 하나의 구성 요소만 변경한 다음 실패한 URL을 다시 테스트하세요. 오류가 사라지면 다시 활성화하기 전에 호환성, 구성을 확인하고 이용 가능한 업데이트가 있는지 조사하세요.

4. Apache에서만 .htaccess를 테스트하세요

로그에서 .htaccess 구문 분석 오류를 가리키거나 Apache 규칙을 변경한 후 오류가 시작되었다면, 백업을 만든 뒤 SFTP 또는 호스팅 파일 관리자를 통해 .htaccess의 이름을 .htaccess.bak으로 임시 변경하세요. 페이지를 다시 테스트하세요. 정상적으로 작동한다면 파일을 신중하게 복원하거나 다시 만들고 사용자 지정 지시어를 단계적으로 추가하세요. 지원되지 않는 지시어 또는 누락된 Apache 모듈이 근본 원인일 수 있습니다. .htaccess를 요청 구성에 사용하지 않는 Nginx 전용 설정에는 이 단계를 적용하지 마세요.

5. 권한과 소유권을 신중하게 수정하세요

로그에 권한 또는 소유권 오류가 표시되면 문제가 있는 경로를 정상적으로 작동하는 파일 또는 호스팅 제공업체가 문서화한 설정과 비교하세요. 파일에는 644, 디렉터리에는 755가 흔히 사용되지만 올바른 값은 호스트와 배포 모델에 따라 다릅니다. SFTP, SSH 또는 호스팅 파일 관리자를 통해 문제가 있는 경로를 수정하고, 지름길로 파일이나 디렉터리를 전체 사용자에게 쓰기 가능하게 만들지 마세요.

6. PHP 및 애플리케이션 리소스 제한을 조사하세요

로그에 메모리 고갈, 최대 실행 시간 또는 유사한 제한이 언급되면 대규모 가져오기나 비용이 큰 플러그인 작업처럼 리소스를 소비하는 작업을 확인하세요. 호스트에서 허용하는 경우에만 해당 php.ini, .user.ini, 호스팅 설정 또는 배포 구성에서 memory_limit 또는 max_execution_time을 조정하세요. 또한 작업량을 줄이거나 비효율적인 작업을 수정하세요. 제한만 늘리면 오류 발생이 지연될 뿐일 수 있습니다.

7. 배포 설정과 필요한 파일을 비교하세요

배포 또는 마이그레이션 후 오류가 시작되었다면 정상 환경과 문제가 있는 환경의 환경 변수, 데이터베이스 자격 증명, 런타임 버전, 설치된 종속성, 파일 경로 및 생성된 구성을 비교하세요. 필요한 파일이 존재하고 애플리케이션이 구성된 데이터베이스 또는 서비스에 연결할 수 있는지 확인하세요. 관련 없는 설정을 변경하기보다 로그에 표시된 누락 변수, 패키지 또는 연결 오류를 출발점으로 삼으세요.

8. 증거를 보존한 후에만 손상된 파일을 복원하세요

업데이트가 불완전했거나 코어 파일이 손상되었다는 징후가 있다면 복구하기 전에 관련 로그와 현재 파일의 사본을 저장하세요. 그런 다음 정상 파일을 복원하거나 플랫폼에서 지원하는 업데이트 프로세스를 다시 실행하고, 가능하면 백업을 사용하세요. 원래 URL을 다시 테스트하고 새로 일치하는 오류가 로그에 기록되지 않는지 확인하세요.

예방 및 해결 확인 방법

• 플러그인, 테마, 모듈 또는 CMS 구성 요소를 설치하거나 업데이트하기 전에 파일과 데이터베이스를 모두 백업하세요.
• 가능하면 스테이징 복사본에서 코드와 .htaccess 변경을 테스트하고, 롤백을 위해 정상 작동하는 구성을 보관하세요.
• 환경 간 구성 변수와 종속성을 일관되게 배포하고, 마이그레이션 후 필요한 파일이 있는지 확인하세요.
• 외부 가용성 확인에만 의존하지 말고 PHP, 애플리케이션 및 웹 서버 오류 로그를 모니터링하세요.
• 한 번에 하나의 변경만 수행하고 변경 내용을 기록한 뒤 실패한 정확한 URL을 다시 테스트하세요.
• 운영 사이트에서는 자세한 진단 정보를 방문자에게 표시하지 말고 서버 측 로그에 기록하세요.

자주 묻는 질문