Proxy Squid en Ubuntu 24.04: instalación, login y squid.conf

Un equipo de datos de cinco personas quiere que sus servidores de pruebas descarguen los paquetes desde un único punto y que lleguen a la API de un proveedor siempre desde la misma dirección IP. Alguien instala Squid en un VPS pequeño en diez minutos. Una semana después, access.log está lleno de direcciones que nadie reconoce: la configuración salió de un post de un foro que terminaba en http_access allow all, y ahora hay desconocidos que sacan su tráfico por la IP del equipo.

Esta guía instala Squid en Ubuntu 24.04 sin cometer ese error. Explica qué es Squid, en qué orden revisa una petición y qué puede darte un solo servidor y qué no. Después viene un archivo de configuración completo con una lista de IP autorizadas, usuario y contraseña, caché en disco y ajustes de cabeceras; un proxy padre con cache_peer, y los comandos para probarlo.

¿Qué es un proxy Squid?#

Squid es un servidor proxy con caché de código abierto. Un servidor proxy envía peticiones en tu nombre y te devuelve las respuestas (Qué es un servidor proxy). Squid suele funcionar como forward proxy, que trabaja para los clientes que tiene detrás, y no como reverse proxy delante de un sitio web (Forward proxy y reverse proxy). Transporta HTTP, HTTPS mediante túneles CONNECT y FTP, con reglas de acceso, programas auxiliares de autenticación (helpers), una caché y un registro de peticiones.

La versión estable actual del proyecto Squid es la 7.7, publicada el 24 de agosto de 2026, y sus desarrolladores solo dan soporte a la última versión estable. Ubuntu 24.04 incluye Squid 6.14, paquete 6.14-0ubuntu0.24.04.4 en noble-updates, y sus correcciones de seguridad llegan con las actualizaciones normales de Ubuntu. Esta guía usa ese paquete.

¿Cómo gestiona Squid una petición?#

El orden de estos pasos explica la mayoría de los errores de configuración.

1. El cliente se conecta al puerto indicado en http_port, el 3128 en la configuración de Ubuntu.
2. Squid lee las líneas http_access de arriba abajo. Decide la primera línea cuyas condiciones se cumplen todas. La documentación de http_access añade que, si ninguna línea coincide, Squid hace lo contrario de lo que dice la última, así que toda lista debe terminar con http_access deny all.
3. Una regla que exige inicio de sesión lo pide. Cuando Squid llega a una condición proxy_auth sin credenciales válidas, responde 407 Proxy Authentication Required (Autenticación de proxy).
4. El HTTP sin cifrar se busca en la caché. Una copia guardada y vigente es un acierto (hit) y la petición no sale del servidor; todo lo demás es un fallo (miss) y se descarga del sitio.
5. HTTPS se convierte en un túnel. Cuando CONNECT example.com:443 tiene éxito, Squid solo retransmite bytes cifrados. RFC 9110 lo llama «blind forwarding of data», un reenvío a ciegas, así que Squid no puede guardar la página en caché ni añadir cabeceras dentro del túnel.
6. Un proxy padre toma el relevo si lo configuras con cache_peer y never_direct.
7. Squid escribe una línea en access.log con el cliente, el código de resultado, el tamaño, la URL y el nombre de usuario.

¿Qué te da tu propio servidor Squid y qué no?#

Squid te da el control sobre quién se conecta, qué se guarda en caché y qué se registra. Lo que no puede darte es una segunda dirección: un sitio que ve cientos de peticiones por minuto desde esa única IP de centro de datos la frenará o la bloqueará (Proxies residenciales y de centro de datos).

¿Cómo se instala Squid en Ubuntu 24.04?#

apache2-utils añade htpasswd para el archivo de contraseñas. Guardar una copia de solo lectura de la configuración original es lo que recomienda la guía oficial de Ubuntu Server.

sudo apt update
sudo apt install squid apache2-utils
squid -v | head -n 1                       # la versión instalada
systemctl status squid --no-pager          # debe decir "active (running)"

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original
sudo chmod a-w /etc/squid/squid.conf.original

# ¿dónde se leerán tus propias reglas?
grep -n "include /etc/squid/conf.d" /etc/squid/squid.conf
grep -n "^http_access deny all" /etc/squid/squid.conf

Pon tus ajustes en un archivo dentro de /etc/squid/conf.d/, para que las actualizaciones del paquete no los toquen. El empaquetado de Debian, en el que se basa Ubuntu, coloca include /etc/squid/conf.d/*.conf bajo el comentario INSERT YOUR OWN RULE(S) HERE: después de las reglas que bloquean puertos inseguros y antes de http_access allow localhost y http_access deny all. El número de línea del include que muestra grep debe ser menor que el de deny all; si no lo es, escribe tus líneas en squid.conf junto a ese comentario. El archivo debian.conf de esa carpeta fija logfile_rotate 0, porque de los registros se encarga logrotate.

Un team.conf completo para un proxy cerrado#

Guárdalo como /etc/squid/conf.d/team.conf. Sustituye la red de documentación 203.0.113.0/24 por la red de tu oficina o por las IP fijas de tu equipo.

# /etc/squid/conf.d/team.conf
# Se lee dentro de la lista http_access de squid.conf, encima de "http_access deny all".
# No añadas nunca "http_access allow all": convierte este servidor en un proxy abierto.

# 1. Qué redes pueden conectarse
acl team_net src 203.0.113.0/24

# 2. Usuario y contraseña desde /etc/squid/passwords.
#    Deja las líneas auth_param encima de la ACL proxy_auth.
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5 startup=5 idle=1
auth_param basic realm Team proxy
auth_param basic credentialsttl 2 hours
acl team_users proxy_auth REQUIRED

# 3. Permitir solo si se cumplen LAS DOS: la red correcta Y un inicio de sesión válido.
#    Todo lo demás cae en "http_access deny all".
http_access allow team_net team_users

# 4. No pasar las direcciones de los clientes en peticiones HTTP sin cifrar
forwarded_for delete
via off

# 5. Caché: memoria, objeto más grande que se guarda y luego la caché en disco
cache_mem 512 MB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 10000 16 256

Después añade usuarios, comprueba la sintaxis, reinicia una vez y abre el puerto solo a direcciones conocidas:

sudo htpasswd -c /etc/squid/passwords team1   # -c crea el archivo: solo con el primer usuario
sudo htpasswd /etc/squid/passwords team2      # usuarios siguientes: sin -c
sudo chown root:proxy /etc/squid/passwords
sudo chmod 640 /etc/squid/passwords

sudo squid -k parse                           # muestra errores y avisos, si los hay
sudo systemctl restart squid                  # una vez, por el nuevo cache_dir
sudo tail -n 20 /var/log/squid/cache.log      # mensajes de arranque

sudo ufw allow OpenSSH                        # mantiene accesible tu sesión SSH
sudo ufw allow from 203.0.113.0/24 to any port 3128 proto tcp
sudo ufw enable

¿Cómo se escriben las reglas acl y http_access?#

Una línea acl da nombre a una condición; una línea http_access combina nombres en una decisión. Las condiciones de una misma línea deben cumplirse todas, así que allow team_net team_users significa «desde nuestra red y con sesión iniciada». Las líneas separadas son alternativas: para una segunda oficina, añade acl office2 src 198.51.100.0/24 y http_access allow office2 team_users.

La posición importa tanto como el contenido. Un allow situado debajo de http_access deny all nunca se alcanza, y todos los clientes reciben 403. No toques las reglas que están encima del include: deny CONNECT !SSL_ports solo deja que los túneles lleguen al puerto 443. RFC 9110 recomienda limitar CONNECT a puertos conocidos, porque un proxy que abre túneles a cualquier puerto puede usarse para reenviar spam al puerto 25.

Para cambiar el puerto, edita la línea http_port 3128 que ya existe en squid.conf en lugar de añadir una segunda, y actualiza el firewall. Un puerto nuevo no protege nada; lo que protegen son la ACL y el firewall. Qué significan el 3128 y el 8080 lo explicamos en El puerto 8080 y otros puertos de proxy.

¿Cómo se añaden un usuario y una contraseña?#

htpasswd guarda una línea por usuario con la contraseña en forma de hash. Su hash por defecto es MD5, que el helper basic_ncsa_auth de Squid sabe leer; en Ubuntu, el helper está en /usr/lib/squid/basic_ncsa_auth. Se ejecuta como el usuario proxy, de ahí el grupo proxy del archivo. Las líneas auth_param arrancan hasta cinco helpers, fijan el texto que aparece al pedir el inicio de sesión y hacen que Squid confíe en un inicio de sesión correcto durante dos horas antes de volver a consultar el archivo.

La documentación de auth_param de Squid indica que al cliente solo se le piden credenciales cuando una regla http_access evalúa una ACL proxy_auth. Si configuras auth_param sin usar team_users en http_access, Squid nunca pide la contraseña.

La autenticación básica envía la contraseña codificada en Base64, no cifrada, en cada cabecera Proxy-Authorization entre el cliente y Squid. Cualquiera que observe ese tramo puede leerla, y por eso la lista de IP autorizadas se mantiene junto a la contraseña. Cómo interpretar un 407 lo explicamos en Autenticación de proxy.

¿Cómo se configura la caché y se leen los registros?#

cache_mem fija la memoria para los objetos más solicitados (256 MB por defecto). cache_dir ufs /var/spool/squid 10000 16 256 añade hasta 10.000 MB de caché en disco repartidos en 16 carpetas de primer nivel y 256 de segundo nivel; la documentación de Squid desaconseja indicar el tamaño completo del disco. maximum_object_size vale 4 MB por defecto, lo que deja sin caché los paquetes más grandes, así que súbelo. Esta directiva fija el límite de tamaño por defecto de cada cache_dir, y por eso el archivo de arriba la coloca antes.

squid -z crea las carpetas de la caché, y el archivo de servicio de Ubuntu ejecuta squid --foreground -z antes de cada arranque, así que el reinicio las crea. Para cambios posteriores de reglas o usuarios, sudo systemctl reload squid envía la misma señal que squid -k reconfigure.

La caché solo ayuda con HTTP sin cifrar. Los mirrors de Ubuntu suelen usar direcciones http:// y apt comprueba las firmas de los paquetes, así que las máquinas de CI que dirigen apt a Squid descargan cada paquete una sola vez (Configurar proxy en Linux). HTTPS nunca produce un acierto. Abrirlo para la caché (SSL bump) exige el certificado de Squid en cada cliente y el paquete aparte squid-openssl, y queda fuera de esta guía.

/var/log/squid/access.log tiene una línea por petición, y cache.log guarda los mensajes de arranque y los errores; logrotate rota los dos a diario y conserva dos copias antiguas. El código de resultado te dice qué pasó:

¿Cómo se eliminan las cabeceras Via y X-Forwarded-For?#

Por defecto, Squid añade la IP del cliente a X-Forwarded-For (forwarded_for on) y agrega una cabecera Via (via on). forwarded_for delete elimina la cabecera, off escribe unknown en lugar de la dirección, y via off quita Via. Las dos solo actúan sobre HTTP sin cifrar; dentro de un túnel Squid no añade nada de todos modos. Para comprobar el resultado con una petición de eco, consulta Proxy transparente, anónimo y élite.

Una salida para todo el equipo: cache_peer con un proxy padre#

Un equipo que usa un proxy comercial quizá no quiera tener su contraseña en cada máquina y en cada trabajo de CI. Squid puede ponerse en medio: cada persona inicia sesión en Squid con su propia cuenta, y solo el servidor conoce las credenciales comerciales. Añade a team.conf:

# Envía todas las peticiones por el proxy padre. Los clientes nunca ven su contraseña.
cache_peer pr.proxynet.io parent 8000 0 no-query default login=user:pass
never_direct allow all

Según la documentación de cache_peer: host, tipo parent, puerto del proxy 8000 y puerto ICP 0, porque el peer no responde a consultas ICP. no-query desactiva esas consultas, default lo convierte en el padre de último recurso y login= envía las credenciales del padre; un % en la contraseña se escribe %%.

Sin never_direct allow all, Squid puede atender algunas peticiones directamente desde la IP propia del VPS. Con HTTPS, Squid pasa el CONNECT al padre. En access.log, el campo de jerarquía nombra entonces al padre con un código como DEFAULT_PARENT en lugar de HIER_DIRECT.

Cambiar la contraseña pasa a ser una línea y un reload, cada petición queda registrada con el nombre de usuario de quien la hizo, y el HTTP sin cifrar se sigue guardando en caché. Con Proxies rotativos como padre, el proveedor cambia la IP de salida mientras Squid mantiene una sola dirección (Qué es la rotación de IP). La cadena sirve para gestionar credenciales; no oculta quién eres, y las condiciones del proveedor y las reglas de cada sitio siguen aplicándose.

¿Cómo se conecta un cliente y se prueba?#

Ejecuta esto desde una máquina de la red autorizada; 198.51.100.20 representa tu servidor.

# 1. Sin inicio de sesión: Squid lo pide
curl -x http://198.51.100.20:3128 https://httpbin.org/ip
# curl: (7) CONNECT tunnel failed, response 407

# 2. Con inicio de sesión: la respuesta muestra la IP del servidor, no la tuya
curl -x http://team1:pass@198.51.100.20:3128 --retry 3 https://httpbin.org/ip

# 3. En el servidor: las tres últimas peticiones
sudo tail -n 3 /var/log/squid/access.log

Probamos la parte de curl con curl 8.21 contra un proxy de pruebas local que exige inicio de sesión: el primer comando imprimió la línea de arriba y el segundo devolvió la dirección de salida del proxy. --retry 3 repite tras un tiempo de espera agotado o un código HTTP transitorio como 429 o 503, nunca tras un 407. Tienes más detalles en Cómo usar cURL con proxy y Cómo probar un proxy.

¿Para qué sirve tu propio servidor proxy?#

• Una IP de salida fija para una API: solo el tráfico de la API pasa por Squid (IP estática para API).
• Control del acceso web en la oficina: ACL dstdomain y access.log, avisando antes a los empleados (Proxy o firewall).
• Ajustes del navegador en la oficina: un archivo PAC le indica a cada navegador cuándo usar Squid (Archivo PAC).
• Una caché de paquetes para máquinas de CI: apt descarga cada paquete HTTP sin cifrar una sola vez (Configurar proxy en Linux).
• No para trabajo con datos de varios países: la comparación de precios y el scraping por ubicación necesitan muchas direcciones (extracción de datos).

Errores comunes#

• http_access allow all. Un proxy abierto, cuya IP acaba pronto en listas de bloqueo (Lista negra de IP).
• auth_param sin proxy_auth en http_access. Nunca se pide la contraseña.
• Un allow debajo de deny all. Nunca se alcanza; todos reciben 403.
• El 3128 abierto a internet. Una contraseña sola invita a adivinarla, y la autenticación básica la envía sin cifrar.
• Esperar aciertos de caché con HTTPS. Los túneles nunca se guardan en caché.
• Saltarse squid -k parse. Un error tipográfico detiene el servicio; journalctl -u squid muestra el motivo.
• Dejar maximum_object_size en 4 MB para una caché de paquetes, o un cache_dir mayor que el espacio libre en disco.
• Scraping intensivo desde la IP del VPS. Los sitios responden 429 y luego bloquean (Códigos de estado HTTP en web scraping).

Guía de decisión#

Preguntas frecuentes#

¿Qué puerto usa Squid?#

La configuración de Ubuntu fija http_port 3128, así que Squid escucha en el 3128 tras la instalación. Puedes cambiar esa línea y la regla del firewall a la vez, pero otro puerto no añade protección; la dan la ACL de red, la autenticación y el firewall. Qué significan los números de puerto de proxy más habituales lo explicamos en nuestra guía del puerto 8080.

¿Squid puede guardar en caché sitios HTTPS?#

No con su configuración por defecto. Una petición HTTPS llega como un túnel CONNECT, y Squid retransmite bytes cifrados sin ver la página, así que no hay nada que guardar. SSL bump, que abre el tráfico, necesita un certificado de Squid en cada dispositivo cliente y el paquete squid-openssl, y queda fuera de esta guía.

¿Cómo aplico cambios en squid.conf sin detener el servicio?#

Ejecuta primero sudo squid -k parse, para que un error tipográfico no tumbe el proxy. Después ejecuta sudo systemctl reload squid, que envía la misma señal que squid -k reconfigure y mantiene el servicio en marcha. Si añades o mueves un cache_dir, reinicia una vez en su lugar, para que el servicio cree las carpetas de la caché.

¿Dónde están los registros de Squid y cómo se leen?#

En Ubuntu están en /var/log/squid/: access.log tiene una línea por petición y cache.log los mensajes de arranque y los errores. En access.log, fíjate en el código de resultado: TCP_HIT salió de la caché, TCP_MISS del sitio, TCP_TUNNEL es HTTPS, y TCP_DENIED con 407 o 403 significa rechazado.

¿Qué diferencia hay entre Squid y Tinyproxy?#

Tinyproxy se describe como un daemon proxy HTTP y HTTPS ligero para sistemas demasiado pequeños para un proxy completo, y su manual de configuración no incluye ajustes de caché. Squid añade caché en memoria y en disco, ACL detalladas, varios helpers de autenticación y cadenas de proxies padre. Para un reenvío simple en un dispositivo pequeño, Tinyproxy puede bastar.

¿Mi propio servidor Squid oculta mi identidad?#

Solo en parte. Los sitios ven la IP del VPS en lugar de la dirección de tu casa, y forwarded_for delete con via off quita las cabeceras del proxy en HTTP sin cifrar. Pero esa IP pertenece a un centro de datos, está alquilada a tu nombre y siempre sale del mismo lugar. Squid es una herramienta para el control de acceso y para compartir una salida, no para el anonimato.

En resumen#

Squid te da tu propio forward proxy con control de acceso, una caché para HTTP sin cifrar y un registro de cada petición. Una instalación segura mantiene tres cosas en orden: una ACL de red, una autenticación proxy_auth usada en http_access y http_access deny all al final, con el firewall abierto solo a direcciones conocidas. El límite es la dirección: un servidor es una sola IP de centro de datos en un solo lugar. Cuando un trabajo necesita más direcciones u otros países, los Proxies de centro de datos o los Proxies residenciales cubren ese hueco, y en nuestra página de servicios de proxy comparamos las opciones.