워드프레스 최대 업로드 파일 용량 늘리기
워드프레스 업로드 용량은 세 가지 설정이 함께 결정하며, 이 값들이 서로 맞아야 합니다. 실제 제한은 upload_max_filesize, post_max_size,
게시됨
워드프레스 업로드 용량은 세 가지 설정이 함께 결정하며, 이 값들이 서로 맞아야 합니다. 실제 제한값은 upload_max_filesize, post_max_size, 그리고 웹 서버의 요청 상한 중 가장 작은 값입니다. 하나만 올리고 나머지 둘을 낮게 두면 아무것도 바뀌지 않습니다 — 대부분의 사람들이 “고쳤는데 안 됐다”고 결론 내리는 이유가 바로 이것입니다. 먼저 워드프레스 최대 업로드 용량 도구로 현재 값을 확인하세요. 이 도구는 워드프레스가 보고하는 것과 동일한 값을 읽어, 어느 값이 발목을 잡고 있는지 보여줍니다.
제한이 존재하는 이유와 위치
워드프레스가 업로드 제한을 설정하는 것이 아닙니다. 단지 보고할 뿐입니다. “The uploaded file exceeds the upload_max_filesize directive in php.ini”라는 메시지를 볼 때, 그 메시지는 PHP에서 곧바로 나온 것입니다.
세 개의 개별 값이 업로드를 통제하며, 실제 상한은 그중 가장 낮은 값입니다:
upload_max_filesize(PHP) — PHP가 허용하는 단일 파일의 최대 크기.post_max_size(PHP) — POST 본문 전체의 최대 크기. 파일은 다른 폼 필드와 함께 POST 요청 안에 실려 전송되므로, 이 값은 반드시upload_max_filesize보다 커야 합니다.- 웹 서버의 본문 제한 — Nginx의
client_max_body_size, 또는 Apache의LimitRequestBody. 이 값은 PHP 바깥에 완전히 따로 존재하며, Nginx 뒤에서 PHP만 손보는 방식이 조용히 실패하는 이유가 바로 이것입니다.
네 번째 값인 max_execution_time은 용량을 제한하지는 않지만, 연결 상태가 나쁠 때 느리게 진행되는 대용량 업로드를 전송 도중에 중단시킵니다. 이는 용량 상한과는 무관한 별개의 증상입니다.
함정은 이렇습니다: upload_max_filesize = 256M으로 설정하고 다시 불러왔는데도 100 MB 파일을 여전히 업로드할 수 없습니다 — post_max_size가 아직 8M이기 때문입니다. PHP는 파일을 검사하기도 전에 본문 전체 크기에서 요청을 거부합니다. 방금 올린 제한값이 무시된 게 아닙니다. 다른 제한값이 먼저 걸러낸 것입니다.
순서대로 해결하기
가장 확실하게 먹히는 방법부터 최후의 수단 순으로 진행하세요.
1. php.ini 편집 (제대로 된 위치). 사이트가 실제로 불러오는 파일을 찾으세요 — <?php phpinfo();가 있는 페이지를 실행해 “Loaded Configuration File”을 읽거나, 호스팅 업체에 문의하세요. 두 PHP 값을 모두 설정하되, post_max_size를 upload_max_filesize보다 크게 유지하세요:
upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300
PHP-FPM(sudo systemctl restart php8.2-fpm)이나 Apache를 재시작하세요. PHP 프로세스가 재시작되기 전까지는 변경 사항이 적용되지 않습니다.
2. php.ini에 접근할 수 없나요? .htaccess를 사용하세요 (Apache + mod_php 전용). 워드프레스 루트의 .htaccess에 추가하세요:
php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300
이 방법은 PHP가 Apache 모듈로 실행될 때만 작동합니다. PHP-FPM, CGI, FastCGI 환경에서는 php_value가 500 오류를 냅니다 — 이 오류는 숫자가 틀렸다는 뜻이 아니라, 방향을 잘못 잡았다는 신호입니다. .user.ini로 바꾸세요:
upload_max_filesize = 256M
post_max_size = 260M
3. 웹 서버 제한 올리기 — 모두가 잊어버리는 단계. Nginx에서는 크기 초과 요청을 PHP가 아예 보지도 못합니다. Nginx가 먼저 413 Request Entity Too Large를 반환하기 때문입니다. 서버 블록에서:
client_max_body_size 256M;
sudo nginx -t && sudo systemctl reload nginx로 다시 불러오세요. Nginx를 쓰고 있는데 PHP를 손봐도 “아무 변화가 없다”면, 거의 항상 이것이 원인입니다.
변경한 뒤에는 보고되는 값을 다시 확인하세요. 최대 업로드 용량 도구가 새로운 실제 상한을 알려주고, 여러분의 환경에 맞는 정확한 코드 조각까지 생성해 주므로, 세 값 중 어느 것이 아직 낮은지 추측할 필요가 없습니다.
하지 말아야 할 것
wp-config.php를 편집하면 제한이 풀릴 거라고 기대하지 마세요. 널리 복사되는 이 줄은 블로그 글들이 주장하는 대로 작동하지 않습니다:
@ini_set( 'upload_max_filesize' , '256M' );
upload_max_filesize는 PHP_INI_PERDIR입니다. ini_set()으로 실행 중에 PHP에서 변경할 수 없습니다. 이 값은 오직 php.ini, .htaccess, .user.ini에서 온 새 값만 받아들이며 — 애플리케이션 코드에서는 절대 받아들이지 않습니다. 이 줄은 오류 없이 실행되면서도 아무 일도 하지 않는데, 그래서 워드프레스에서 가장 자신 있게 반복되는 잘못된 조언 중 하나가 되었습니다.
@ini_set('post_max_size', ...)도 붙여넣지 마세요 — 같은 제약, 같은 조용한 무효과입니다.
WP_MEMORY_LIMIT를 설정하고 그게 업로드 제한이라고 생각하지 마세요. 그것은 코드를 실행할 때 PHP가 쓰는 메모리 상한을 제어합니다. 서버가 얼마나 큰 파일을 받아들이는지와는 무관합니다.
파일 하나에서 멈추지 마세요. 가장 흔한 실패는 upload_max_filesize만 바꿔 놓고 해결책이 안 먹힌다고 단정하는 것입니다. 세 값을 모두 바꾸고, post_max_size를 upload_max_filesize보다 높게 유지하세요.
“안전하게 하려고” 제한을 터무니없이 높게 설정하지 마세요. 2 GB 제한은 자원 고갈 문제를 불러오고 도움도 되지 않습니다 — 정말로 수 기가바이트짜리 파일이 필요하다면, 단일 PHP POST로 억지로 밀어넣지 말고 브라우저 바깥에서 업로드하세요(SFTP, 또는 청크 업로드 플러그인).
여전히 막혔나요?
세 값을 모두 올렸는데도 벽에 부딪힌다면, 요청이 서버보다 상위 어딘가에서 제한되고 있는 것입니다: CDN이나 프록시(Cloudflare 대시보드는 자체적으로 업로드 본문 크기를 제한합니다), 여러분의 php.ini를 무시하는 관리형 호스팅의 플랫폼 제한, 또는 아직 갱신되지 않은 .user.ini입니다 — .user.ini는 PHP의 user_ini.cache_ttl을 따르므로 저장 후 몇 분간 반영이 지연될 수 있습니다. 파일에 쓴 내용이 아니라 서버가 실제로 보고하는 값을 확인하고, 아직 낮은 계층을 고치세요. 보고되는 숫자가 마침내 목표값과 일치하면, 업로드가 작동합니다.