Límites de subida de tu servidor

Tarde o temprano una subida falla: un itemInfo.lua de 40 MB, los archivos de spawn en bloque, un parche del cliente. El mensaje casi nunca dice qué límite se alcanzó, y hay tres que pueden ser el culpable. Esta guía los recorre en el orden en que actúan y te deja los valores que recomendamos.

1 · Los tres techos y cuál manda #

Una subida atraviesa tres puertas, y la más baja es la que decide:

1. Tu servidor web (nginx o Apache) es el primero en mirar. Si el archivo supera su límite, corta con un error 413 y ni PHP ni rApanel se enteran de que alguien lo intentó.
2. PHP mira después, con upload_max_filesize y post_max_size. Aquí el rechazo sí llega al panel, que lo muestra como un error de validación normal.
3. rApanel aplica por último su propio tope por módulo.

2 · Los límites de PHP #

Estos cuatro se ajustan sin tocar la configuración del sistema ni reiniciar nada: van en el archivo public/.user.ini de tu instalación de rApanel, que PHP-FPM lee por sí solo.

# public/.user.ini
upload_max_filesize = 64M
post_max_size       = 80M
memory_limit        = 512M
max_execution_time  = 120

• upload_max_filesize — el archivo más grande que acepta PHP.
• post_max_size — el total del envío. Tiene que ser igual o mayor que el anterior, porque además del archivo viajan los campos del formulario. Si queda por debajo, el archivo se descarta sin aviso claro.
• memory_limit — los importadores de Item DB y Mob DB procesan archivos grandes en memoria.
• max_execution_time — un import grande puede tardar más que el minuto por defecto y morir a mitad de camino.

3 · max_file_uploads, la excepción #

Limita cuántos archivos entran en un mismo envío, no su tamaño. El valor por defecto es 20, y es el que estorba al importar los archivos de spawn de rAthena en bloque: PHP descarta los que sobran sin decir nada, así que la importación parece funcionar y en realidad quedó a medias.

# /etc/php/8.4/fpm/conf.d/99-rapanel.ini
max_file_uploads = 200

sudo systemctl reload php8.4-fpm

Se usa un archivo aparte en conf.d en lugar de editar el php.ini para que una actualización de PHP no se lleve el cambio por delante.

4 · El servidor web #

Es el que corta primero y el que produce el 413. El panel lo mide de verdad —le pregunta a tu propio servidor si aceptaría un archivo de ese tamaño, sin llegar a enviarlo— y te dice el número exacto.

nginx. Conviene ponerlo dentro del bloque del sitio, no en el http { } general: así solo sube el límite del panel y no el de los demás sitios que tengas en la misma máquina.

# /etc/nginx/sites-available/tu-sitio — dentro de server { }
client_max_body_size 64M;

sudo nginx -t && sudo systemctl reload nginx

Apache. En el virtual host del panel o en su .htaccess. El valor va en bytes:

LimitRequestBody 67108864

sudo apachectl configtest && sudo systemctl reload apache2

Deja este límite igual o algo mayor que el de PHP. Si el servidor web queda por encima, quien rechaza es PHP y el panel puede mostrar un mensaje claro; al revés, el visitante recibe un 413 crudo del servidor y nadie se entera.

5 · Archivos de cientos de MB #

Para el cliente del juego o un parche completo, la respuesta no es seguir subiendo límites: por el navegador no van a entrar, y si entran, una conexión que se corte a mitad te obliga a empezar de cero. Esos archivos se dejan por FTP o SFTP en la carpeta correspondiente del servidor y el panel los detecta solo — tanto en Admin → Descargas como en Admin → Patcher, que muestran la ruta exacta.

El detalle está en la guía de publicar el cliente del juego, que además explica cómo conseguir que la descarga se pueda reanudar.

6 · Valores recomendados #

Con esto funcionan holgados todos los importadores del panel:

• upload_max_filesize — 64M · en public/.user.ini
• post_max_size — 80M · en public/.user.ini
• memory_limit — 512M · en public/.user.ini
• max_execution_time — 120 · en public/.user.ini
• max_file_uploads — 200 · en conf.d de PHP-FPM
• client_max_body_size — 64M · en el bloque del sitio en nginx