워드프레스 최대 업로드 용량 오류 해결법: PHP·웹서버·CyberPanel 설정 확인
한 곳의 숫자만 올리지 말고 실제 사이트가 사용하는 PHP 버전과 모든 제한 계층을 확인한 뒤 필요한 범위만 조정하고 재시작·업로드 테스트를 수행하세요.
워드프레스 업로드 한도는 관리자 화면의 숫자 하나가 아니라 PHP, 웹서버, 프록시와 애플리케이션 제한 중 가장 작은 값으로 결정됩니다.
`upload_max_filesize`만 크게 바꿨는데 오류가 계속되는 이유는 `post_max_size`, 웹서버 요청 본문 제한, 사이트가 실제 사용하는 PHP 풀과 재시작 여부가 맞지 않을 수 있기 때문입니다. 413 오류와 WordPress 자체 메시지도 원인이 다를 수 있습니다.
무조건 2GB로 키우기보다 실제 업무에 필요한 파일 크기와 보안·시간 제한을 정하세요. 대형 백업이나 동영상은 관리자 업로드보다 SFTP, 객체 저장소나 전용 이전 도구가 더 안전할 수 있습니다.
오류 위치별 점검 계층
표시되는 메시지와 HTTP 상태를 먼저 구분하면 불필요한 설정 변경을 줄일 수 있습니다.
| 증상 | 가능한 제한 | 확인 위치 |
|---|---|---|
| WordPress에 낮은 최대치 표시 | PHP upload_max_filesize·post_max_size | 사이트 상태·phpinfo·해당 PHP 설정 |
| HTTP 413 | 웹서버·프록시 요청 본문 제한 | OpenLiteSpeed·Nginx·CDN 로그 |
| 업로드 후 시간 초과 | max_execution_time·메모리·네트워크 | PHP·웹서버 오류와 자원 |
| 한 사이트만 다름 | 사이트별 PHP 풀·vhost 설정 | CyberPanel 사이트 관리 |
| CLI는 되고 웹만 실패 | 웹 SAPI와 CLI PHP 설정 차이 | 각 PHP 경로·ini 파일 |
필요한 최대 크기를 먼저 정합니다
일반 이미지와 문서 업로드라면 수십 MB를 넘길 이유가 드물 수 있습니다. 테마·플러그인 ZIP, 데이터 가져오기와 백업 복원은 더 큰 한도가 필요할 수 있으므로 작업 유형별로 목표를 정합니다.
영상이나 수백 MB 백업을 WordPress 관리자에서 직접 올리면 요청 시간과 메모리를 많이 사용합니다. 대형 파일은 SFTP·SSH·스토리지 연동이나 호스팅 복원 기능을 검토하세요.
PHP의 세 설정을 함께 봅니다
`upload_max_filesize`는 개별 업로드 파일 한도이고 `post_max_size`는 요청 전체 본문 한도입니다. 여러 파일과 폼 데이터가 함께 전송되므로 post_max_size를 더 크게 두는 것이 일반적입니다.
`memory_limit`과 `max_execution_time`도 이미지 처리·압축 해제에서 영향을 줄 수 있지만 무작정 높이지 마세요. 실제 오류 로그와 작업 특성에 맞춰 최소한으로 조정합니다.
사이트가 사용하는 PHP 버전과 ini를 확인합니다
CyberPanel에서 전역 PHP 값을 바꿔도 사이트가 다른 버전이나 별도 풀을 사용하면 적용되지 않을 수 있습니다. WordPress 사이트 상태와 `phpinfo`를 임시로 확인해 로드된 설정 파일과 값을 봅니다.
확인용 phpinfo 파일은 민감한 서버 정보를 노출하므로 인증된 환경에서 짧게 사용하고 즉시 삭제합니다. CLI의 `php -i` 결과와 웹 요청 결과가 다를 수 있습니다.
웹서버와 프록시 제한을 확인합니다
OpenLiteSpeed·LiteSpeed, Nginx, Apache와 CDN은 요청 본문 크기를 별도로 제한할 수 있습니다. PHP 값보다 작은 제한이 있으면 요청이 WordPress에 도달하기 전에 413으로 거절됩니다.
적용 위치를 모른 채 여러 설정 파일을 동시에 바꾸지 마세요. 요청 ID와 오류 로그를 통해 거절한 계층을 확인하고 해당 서비스만 변경·재시작합니다.
변경 후 실제 업로드와 복구를 테스트합니다
관리자 화면의 숫자가 바뀌었다고 완료하지 말고 목표 크기보다 작은 파일, 경계에 가까운 파일과 초과 파일을 업로드해 예상대로 동작하는지 확인합니다. 이미지라면 썸네일 생성과 메타데이터 처리까지 봅니다.
설정 변경 전 파일을 보관하고 이전 값으로 되돌리는 명령과 담당자를 기록하세요. 지나치게 큰 허용치는 디스크 고갈과 요청 남용 위험을 키울 수 있습니다.
업로드 한도 오류 해결 8단계
현재 값과 오류를 캡처한 뒤 한 계층씩 수정하세요.
- 실패 파일의 크기·형식과 화면 메시지·HTTP 상태를 기록합니다.
- WordPress가 표시하는 최대 업로드 크기와 사이트 상태를 확인합니다.
- 웹 요청이 사용하는 PHP 버전과 로드된 ini 파일을 확인합니다.
- upload_max_filesize, post_max_size, memory_limit과 실행 시간을 대조합니다.
- 웹서버·CDN·리버스 프록시의 요청 본문 제한과 오류 로그를 확인합니다.
- 필요한 최소 범위로 한 계층을 수정하고 관련 서비스를 재시작합니다.
- 작은·경계·초과 파일로 업로드와 후처리를 테스트합니다.
- 설정 파일, 변경 이유, 적용 시각과 롤백 값을 운영 문서에 남깁니다.
백업 복원 같은 일회성 작업을 위해 한도를 올렸다면 작업 후 원래 운영 값으로 낮추고 임시 파일과 디스크 사용량을 정리하세요.
설정을 바꿔도 해결되지 않는 이유
| 실수 | 결과 | 수정 |
|---|---|---|
| upload_max_filesize만 변경 | post_max_size나 웹서버가 더 작을 수 있습니다. | 모든 제한 계층을 표로 비교합니다. |
| CLI PHP만 확인 | 웹사이트 PHP 설정과 다를 수 있습니다. | 웹 SAPI의 실제 값을 확인합니다. |
| 재시작·재로드 생략 | 이전 설정이 계속 사용됩니다. | 해당 PHP·웹서버 적용 절차를 실행합니다. |
| 한도를 무제한에 가깝게 확대 | 남용·디스크·메모리 위험이 커집니다. | 업무에 필요한 최소값을 사용합니다. |
설정 파일 편집은 백업과 롤백 경로를 확보한 뒤 진행하세요. 관리 패널 값과 실제 서버 값이 다르면 패널 문서와 로그를 기준으로 조사합니다.
업로드 성공뿐 아니라 자원 영향을 확인합니다
큰 파일 업로드 동안 PHP 메모리, CPU, 디스크 임시 공간, 요청 시간과 5xx를 확인합니다. 이미지 후처리와 압축 해제가 서버를 멈추게 하지 않는지도 중요합니다.
반복적으로 큰 파일을 올리는 업무라면 관리자 업로드를 늘리는 대신 전용 저장·전송 절차를 설계하는 편이 안정적입니다.
- 목표 크기 파일의 업로드·후처리 성공
- 413·타임아웃·PHP 오류 빈도
- 업로드 중 CPU·메모리·디스크 사용
- 웹·CLI PHP 설정의 일치
- 설정 변경과 재시작·롤백 기록
- 대형 파일의 대체 전송 경로 사용률
업로드 실패 메시지로 병목 계층을 찾는 방법
업로드 화면에 표시되는 최대 크기와 실제 서버가 허용하는 요청 크기는 다를 수 있습니다. 파일 크기와 오류 문구, HTTP 응답 코드부터 기록해 어느 제한에 걸리는지 구분하세요.
PHP 설정의 upload_max_filesize와 post_max_size는 함께 확인해야 합니다. 요청 전체 크기는 파일 외의 값까지 포함하므로 후자의 제한이 더 낮으면 예상치 못한 실패가 생길 수 있습니다.
웹서버나 프록시에도 요청 크기 제한이 있을 수 있습니다. PHP 설정만 높였는데도 413 응답이 나온다면 그 앞단의 제한과 현재 적용된 가상 호스트 설정을 살펴보세요.
서버 설정을 수정해도 즉시 반영되지 않을 수 있습니다. 관련 프로세스 재시작이 필요한 환경인지 확인하고 운영 중인 다른 사이트에도 영향을 미치는 공통 설정인지 구분해야 합니다.
용량 제한을 크게 늘리는 것이 항상 최선은 아닙니다. 특히 이미지라면 업로드 전에 크기를 줄이거나 적절한 파일 형식으로 변환해 대역폭과 저장 비용을 함께 줄일 수 있습니다.
일시적으로 업로드를 허용한 뒤에는 허용 파일 형식과 관리자 권한을 확인합니다. 서버가 큰 파일을 처리하게 되면 처리 시간과 메모리 사용도 달라질 수 있습니다.
배포 전 검증에는 작은 정상 파일, 제한 근처 파일, 허용되지 않은 형식의 파일을 각각 사용하세요. 실패했을 때 사용자에게 이해할 수 있는 안내가 표시되는지도 중요합니다.
자주 묻는 질문
upload_max_filesize만 올리면 되나요?
대개 post_max_size가 더 커야 하며 memory_limit, 웹서버·프록시 제한과 실행 시간도 확인해야 합니다. 가장 낮은 제한이 실제 한도가 됩니다.
php.ini를 수정했는데 값이 안 바뀌는 이유는 무엇인가요?
다른 PHP 버전이나 FPM 풀의 설정을 수정했거나 서비스 재시작이 반영되지 않았을 수 있습니다. Site Health 또는 phpinfo로 실제 런타임 값을 확인하세요.
무조건 큰 업로드 한도가 좋은가요?
아닙니다. 큰 요청은 메모리·시간·보안 부담을 늘립니다. 실제 백업·미디어 작업에 필요한 범위만 허용하고 다른 업로드 경로를 분리하세요.
미디어 파일은 FTP로 올리면 라이브러리에 바로 보이나요?
파일만 배치하면 WordPress 첨부 데이터가 생성되지 않을 수 있습니다. 미디어 등록 도구나 WP-CLI 등 검증된 절차를 사용하세요.
함께 읽으면 좋은 INXSEO 가이드
CyberPanel 설치, 서버 자원과 SSH 운영 글을 함께 보면 업로드 한도를 애플리케이션과 서버 계층으로 나눠 이해할 수 있습니다.
공식 확인 자료
CyberPanel 화면과 기본값은 버전에 따라 달라질 수 있으므로 현재 사이트가 사용하는 PHP와 공식 안내를 확인하세요.
업로드 용량 오류는 가장 작은 제한을 찾는 문제입니다. 실제 요청 경로를 따라 한 계층씩 확인하고 필요한 만큼만 조정하세요.