500 Internal Server Error 뜻과 원인, 해결 방법 (500 에러)

HTTP 오류 500이란?

HTTP 오류 500(Internal Server Error)은 웹 서버가 요청을 처리하는 도중 무언가가 고장 났는데, 서버가 그 원인을 알려 주지 않았다는 뜻입니다. 가장 포괄적인 서버 오류입니다.

HTTP 표준은 500을 한 문장으로 정의합니다. "The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request"(RFC 9110 §15.6.1). 서버가 요청을 처리하지 못하게 하는 예기치 않은 상황을 만났다는 뜻입니다. 503과 달리, 500은 문제가 일시적인지에 대해서는 아무것도 알려 주지 않습니다.

원인은 거의 항상 서버 측 코드의 버그, 잘못된 설정, 크래시이며 방문자가 잘못한 것은 없습니다. 해결은 사이트 소유자나 관리자가 해야 합니다.

500 오류의 표시 형태

표시되는 문구는 서버와 앱에 따라 다릅니다.

• 500 Internal Server Error — 표준 상태 줄
• 500 Internal Server Error 아래에 "nginx" 표시 — nginx 자체의 오류 페이지
• The server encountered an internal error or misconfiguration and was unable to complete your request. — Apache의 기본 페이지
• There has been a critical error on this website. (한국어 사이트: "이 웹사이트에 치명적인 오류가 있습니다.") — WordPress의 치명적 오류 페이지
• HTTP Error 500.19 - Internal Server Error — IIS. 점 뒤의 숫자가 이유를 나타냅니다(500.19: 잘못된 구성 데이터).
• This page isn't working · HTTP ERROR 500 (한국어 Chrome: "페이지가 작동하지 않습니다.") — 500 응답에 자체 페이지가 없을 때 Chrome이 보여 주는 화면
• Request failed with status code 500 — API를 호출하는 Axios 등 JavaScript 코드
• 500. That's an error. (한국어 화면: "500. 오류가 발생했습니다.") — Google 자체 오류 페이지

nginx에서 500 Internal Server Error가 날 때

대부분의 경우 nginx는 그 뒤의 앱(PHP-FPM, Node.js, Python)이 반환한 500을 그대로 전달할 뿐입니다. PHP-FPM이라면 PHP 자체의 오류 메시지가 nginx 로그에 남습니다. nginx가 직접 500을 만드는 경우도 몇 가지 있습니다. 오류 로그에서 찾아야 할 줄은 다음과 같습니다.

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(출처: nginx 소스 코드. 백엔드가 크래시되었거나 과부하 상태라면 500이 아니라 502나 504가 납니다.)

HTTP 오류 500의 주요 원인

500은 수십 가지 서버 측 문제로 발생할 수 있습니다. 흔한 원인은 다음과 같습니다.

• .htaccess 파일 손상 — 잘못된 지시어 하나, 잘못된 RewriteRule 하나만 있어도 Apache는 그 디렉터리와 그 아래 전체에 500으로 응답합니다.
• PHP 치명적 오류(Fatal error) — 구문 오류, 처리되지 않은 예외, 정의되지 않은 함수 호출이 스크립트를 멈춥니다.
• PHP 메모리·시간 제한 — memory_limit(기본값 128M)이나 max_execution_time(30초)을 넘긴 스크립트는 중단됩니다.
• PHP-FPM 서버의 php_value 줄 — 이 줄은 Apache의 mod_php에서만 동작합니다. PHP-FPM에서는 Apache가 이 줄을 거부하고 500으로 응답합니다.
• 잘못된 파일 권한 — PHP가 include하는 파일을 읽지 못하거나, suPHP/suEXEC 호스트가 모든 사용자에게 쓰기 권한이 있는 파일(777)을 거부하는 경우입니다. (웹 서버 자체가 읽지 못하는 파일은 403이 됩니다.)
• 플러그인 또는 테마 — 새로 설치했거나 업데이트한 WordPress, Joomla, Drupal 확장 기능이 사이트 전체를 크래시시킵니다.
• 데이터베이스 연결 실패 — 잘못된 자격 증명, 멈춘 데이터베이스 서버, 연결 수 초과가 원인입니다.
• 코어 파일 손상 — 업데이트가 실패했거나 업로드가 중간에 끊긴 뒤에 생깁니다.
• 디스크 가득 참 — 서버가 로그, 세션, 임시 파일을 쓸 수 없습니다.
• nginx 자체의 원인 — rewrite 루프, 읽을 수 없는 비밀번호 파일, 실패한 임시 파일 쓰기(대개 디스크 가득 참)입니다. 위의 nginx 섹션을 참고하세요.

방문자를 위한 500 오류 해결 방법

다른 사람의 웹사이트에서 500 오류가 표시된다면, 문제는 해당 서버 측에 있습니다. 여러분의 기기 문제가 아닙니다. 하지만 몇 가지 시도해 볼 수 있는 방법이 있습니다.

• 1분 뒤 한 번만 새로고침하기 (F5, Mac에서는 Cmd+R). 배포나 재시작이 진행되는 동안에만 나타났다가 사라지는 500이 많습니다.
• 모두에게 다운되었는지 확인하기 — 사이트 다운 확인은 11곳에서 페이지를 열어 보고, HTTP 헤더 검사는 저희 서버가 받는 정확한 상태 코드를 보여 줍니다.
• 해당 사이트의 쿠키 삭제하기, 또는 시크릿 창에서 열어 보기. 손상된 세션 쿠키 때문에 일부 앱이 나에게만 모든 페이지에서 오류를 낼 수 있습니다.
• 나중에 다시 시도하기 — 해결은 서버 쪽에서 해야 하므로 사이트 소유자에게 시간을 주세요.
• 웹사이트 소유자에게 알리기 — 몇 시간째 계속되면 페이지 주소와 발생 시각을 함께 알려 주세요.

구글에서 "500. That's an error."(500. 오류가 발생했습니다)가 뜰 때

"500. That's an error. There was an error. Please try again later. That's all we know."는 Google 서버가 보내는 기본 500 오류 페이지입니다. 화면 언어가 한국어라면 같은 페이지가 "500. 오류가 발생했습니다. 오류가 발생했습니다. 나중에 다시 시도해 주세요. 다른 원인은 확인할 수 없습니다."로 표시됩니다. Google 계정, Gmail, Google Drive, Google Docs처럼 Google 주소의 여러 서비스가 같은 형식의 오류 페이지를 씁니다.

뜻은 이 글에서 설명한 500과 같습니다. 요청을 처리하던 Google 서버에서 예기치 않은 오류가 났다는 뜻이며, 내 컴퓨터나 인터넷 연결이 고장 났다는 뜻이 아닙니다. 페이지 스스로 "That's all we know."(다른 원인은 확인할 수 없습니다)라고 말하듯 원인은 표시되지 않고, 고치는 것도 Google의 몫입니다. 사용자가 할 수 있는 일은 다음과 같습니다.

• Google 쪽 장애인지 확인하기: Google Workspace 상태 대시보드에서 Gmail, Google Drive, Google Docs, Google Forms, Google 로그인 등 서비스별 현재 상태와 최근 이슈 기록을 볼 수 있습니다. 이슈가 올라와 있다면 복구될 때까지 기다리는 수밖에 없습니다.
• 5분 기다린 뒤 새로고침하기: Google Docs 고객센터는 서버 오류 메시지가 나오면 5분간 기다린 후 페이지를 새로고침하라고 안내합니다.
• 시크릿 창과 확장 프로그램 확인하기: 같은 안내에 따르면 시크릿 창에서 로그인해 열어 보고, 확장 프로그램을 하나씩 사용 중지하면서 문제를 일으키는 것을 찾을 수 있습니다.
• 나에게만 계속 뜬다면: 인터넷 사용 기록, 쿠키, 캐시된 파일을 삭제하거나(이후 다시 로그인해야 할 수 있음) 다른 브라우저나 기기에서 열어 보세요.

참고: 이 방법들은 내 브라우저 쪽 원인을 걸러 낼 뿐, Google 서버의 오류를 고치지는 못합니다. 대시보드에 이슈가 없는데도 몇 시간씩 이어진다면 해당 서비스의 도움말 커뮤니티에 알리세요. 대시보드에 없는 Google 서비스라면 사이트 다운 확인으로 다른 지역에서도 응답하는지 확인할 수 있습니다.

해결 방법 1: 서버 오류 로그 확인

오류 로그는 500 오류 디버깅에서 가장 중요한 도구입니다. 파일 경로, 줄 번호, 오류 메시지를 포함하여 정확히 무엇이 잘못되었는지 알려줍니다. 다른 작업을 시도하기 전에 항상 로그를 먼저 확인하세요.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

해결 방법 2: .htaccess 점검 및 복구

손상된 .htaccess 파일은 Apache에서 500 오류가 나는 대표적인 원인입니다. 오타 하나, 서버가 지원하지 않는 지시어 하나, 잘못된 RewriteRule 하나만으로 해당 디렉터리가 통째로 멈춥니다. Apache 오류 로그에는 .htaccess 파일과 문제의 지시어가 기록됩니다. 예: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

가장 빠른 테스트 방법은 파일 이름을 임시로 변경하는 것입니다. 파일 이름을 변경한 후 사이트가 정상적으로 로드되면 .htaccess가 원인인 것입니다.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

해결 방법 3: 파일 권한 수정

권한 때문에 500이 나는 경우는 PHP가 include하는 파일을 읽지 못할 때, 또는 모든 사용자에게 쓰기 권한이 있는 파일을 거부하는 suPHP/suEXEC 호스트일 때입니다. 일반적인 설정은 파일 644, 디렉터리 755입니다. 777은 절대 쓰지 마세요. 보안 위험일 뿐 아니라 suEXEC/suPHP 호스트에서는 그 자체로 500을 일으킵니다.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

해결 방법 4: PHP 메모리 및 실행 제한 늘리기

PHP는 메모리 제한이나 최대 실행 시간을 넘긴 스크립트를 중단하고, 방문자에게는 500이 표시됩니다. 기본값인 메모리 128M과 30초는 무거운 페이지에는 부족한 경우가 많습니다.

서버가 실제로 읽는 위치에서 값을 높이세요. PHP-FPM이라면 FPM용 php.ini(예: /etc/php/8.3/fpm/php.ini)를 수정하고 php-fpm을 다시 로드하세요. .user.ini 변경은 적용되기까지 최대 5분이 걸릴 수 있습니다.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

해결 방법 5: 플러그인 및 테마 비활성화 (CMS)

WordPress, Joomla 또는 다른 CMS를 사용하는 경우, 결함이 있는 플러그인이나 테마가 500 오류의 가장 흔한 원인 중 하나입니다. 가장 빠른 테스트 방법은 모든 플러그인을 한 번에 비활성화한 후 하나씩 다시 활성화하는 것입니다.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

해결 방법 6: 데이터베이스 연결 확인 및 복구

애플리케이션이 데이터베이스에 연결할 수 없으면 500 오류가 발생할 수 있습니다. 자격 증명이 잘못되었거나, 데이터베이스 서버가 다운되었거나, 테이블이 손상된 경우에 발생합니다.

먼저 설정 파일(WordPress의 경우 wp-config.php, Laravel의 경우 .env)에서 데이터베이스 자격 증명을 확인하세요. 그런 다음 연결을 테스트하고 필요한 경우 손상된 테이블을 복구하세요.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

해결 방법 7: PHP 버전 호환성 확인

이전 PHP 버전용으로 작성된 코드는 새 버전에서 치명적 오류를 낼 수 있습니다(반대의 경우도 마찬가지입니다). PHP 업그레이드 후에는 제거된 함수와 바뀐 동작이 흔한 원인이며, 지원 중단(deprecated) 함수는 알림(notice)만 남깁니다.

사이트가 실제로 쓰는 PHP 버전을 확인하세요. 명령줄의 php -v는 사이트가 쓰는 PHP와 다른 버전을 보여 줄 수 있으므로, 호스팅 패널이나 임시 phpinfo() 페이지에서도 확인하세요.

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

해결 방법 8: 디스크 공간 확인

서버의 디스크 공간(또는 inode)이 바닥나면 로그, 임시 파일, 세션 데이터를 쓸 수 없어 요청이 500으로 실패하기 시작합니다.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504: 차이점은?

핵심 차이: 500 = 서버 내부에서 고장 남. 502 = 프록시가 백엔드로부터 잘못된 응답을 받음. 503 = 서버는 살아 있지만 바쁨. 504 = 프록시가 기다리다 포기함. 서버가 반환하는 정확한 상태 코드는 DNS Robot의 HTTP 헤더 검사로 확인할 수 있습니다.

502가 뜬다면 애플리케이션은 정상이고 문제는 프록시와 앱 사이에 있을 수 있습니다. 이 경우는 502 Bad Gateway 가이드에서 다룹니다.

500 오류가 SEO에 미치는 영향

Google 문서는 다음과 같이 설명합니다(Google 크롤러 문서).

• 크롤링이 느려집니다. 5xx 오류가 나면 Google은 그 사이트의 크롤링 속도를 오류를 반환하는 URL 수에 비례해 낮춥니다.
• 색인된 페이지는 처음에는 유지됩니다. 이미 색인된 URL은 한동안 유지되지만, 계속 서버 오류를 반환하는 URL은 색인에서 삭제됩니다.
• 회복은 점진적입니다. 서버가 다시 2xx로 응답하면 Google은 크롤링을 점차 늘립니다.
• 계획된 다운타임에는 503을 쓰세요. 하루나 이틀 정도라면 Retry-After 헤더와 함께 503을 보내(Google) 일시적인 중단으로 읽히게 하세요(503 가이드).

500 오류를 예방하는 방법

예방이 디버깅보다 항상 낫습니다. 웹사이트에서 500 오류의 위험을 최소화하기 위한 모범 사례를 소개합니다.

• 가동 시간 모니터링 설정 — UptimeRobot이나 Pingdom 같은 도구를 사용하여 1~5분마다 사이트를 확인하세요. 500 오류 발생 시 즉시 알림을 받을 수 있습니다.
• 변경 사항은 항상 스테이징에서 테스트 — 프로덕션에 직접 배포하지 마세요. 플러그인 업데이트, PHP 업그레이드, 설정 변경은 스테이징 환경에서 먼저 테스트하세요.
• 버전 관리(Git) 사용 — 모든 변경 사항을 커밋하면 하나의 명령으로 잘못된 배포를 즉시 되돌릴 수 있습니다.
• 적절한 오류 처리 구현 — 데이터베이스 쿼리와 API 호출을 try-catch 블록으로 감싸세요. 모든 오류에 대해 전체 스택 트레이스를 서버 측에 기록하세요.
• 디스크 공간 및 서버 리소스 모니터링 — 디스크 사용량 80% 초과, 높은 CPU 사용률, 메모리 부족 시 알림을 설정하세요.
• 소프트웨어 최신 상태 유지 — 오래된 CMS 버전, 플러그인, 서버 소프트웨어에는 크래시를 유발하는 알려진 버그가 포함되어 있습니다.
• 자동 백업 유지 — 복원 절차를 정기적으로 테스트하세요. 한 번도 테스트하지 않은 백업은 백업이 아닙니다.
• PHP 제한 값을 적절히 설정 — memory_limit와 max_execution_time을 기본값이 아닌 실제 워크로드에 맞게 설정하세요.
• CI/CD 파이프라인 사용 — 배포 전에 테스트를 자동화하세요. 테스트가 실패하면 배포가 진행되지 않아야 합니다.