Siguiendo con los artículos de optimización de WordPress voy a indicar los que a mi parecer son los plugins más importantes en WordPress.

Hay que tener en cuenta que los plugins suelen ser el principal problema de utilización de recursos en WP, así que cuantos menos tengamos, mejor. Por eso conviene escoger con mucho cuidado los plugins a utilizar. Estos son los que personalmente recomiendo:

• Clean Options Limpia de la base de datos restos de plugins antiguos y registros innecesarios en la tabla options, una de las más importantes de WP y que afectan directamente al rendimiento del sitio.
• WP-Optimize: Permite optimizar la base de datos con un solo click así como eliminar revisiones de entradas y cambiar el nombre de usuario admin por uno personalizado.
• WP Super Cache: Sin duda alguna el plugin más importante que existe en WordPress para sitios con una cantidad importante de visitas.
• Akismet: Este plugin ya viene por defecto en WP y permite que tu blog no se llene de comentarios SPAM.

En relación con optimización estos son los cuatro plugins esenciales (a mi parecer). Por supuesto para otros objetivos como el SEO habría que seleccionar algún plugin más (WordPress Related Posts, All in One SEO Pack…).

Artículos anteriores sobre optimización de WordPress:

Optimización de WordPress: las cabeceras, fichero header.php

Optimización de WordPress: el fichero .htaccess

El fichero oculto .htaccess se utiliza en servidores web Apache, se encuentra en la raíz de nuestro sitio web y en él podemos configurar una serie de directivas de Apache sin necesidad de ser configuradas a nivel global en el servidor.

Entre otras cosas, podemos configurar sistemas de autenticación, url’s amigables, compresión del sitio web, etc. Para optimizar nuestro WordPress hoy añadiremos lo siguiente en dicho fichero:

Activación de caché por Apache con los módulos mod_expires y mod_headers

Antes de nada tenéis que aseguraros que el servidor web apache bajo el que está vuestro sitio web tiene compilados los módulos mod_expires y mod_headers.

El funcionamiento de este sistema es que podemos decir al navegador de la gente que visita nuestra web que ciertos ficheros (normalmente imagenes, css, javascript, etc) pueden ser cacheados durante un tiempo determinado. Si añadís el siguiente código al fichero .htaccess le diréis a los navegadores que cacheen durante un mes esos ficheros. Esto supone que la segunda vez que esta persona acceda a vuestra página no tendrá que volver a descargar las imágenes, css, javascript, etc lo que implica menor uso de transferencia de datos y mayor velocidad en el acceso web:

ExpiresActive On
ExpiresDefault A0
# expiracion de 1 mes para archivos estaticos
<FilesMatch "\.(gif|jpg|jpeg|png|swf|js|css|ico)$">
ExpiresDefault "access plus 1 months"
</FilesMatch>

Activación de compresión por Apache con el módulo mod_deflate

El módulo de Apache (apache 2) mod_deflate permite que el contenido que el servidor proporciona al cliente final (usuario) sea comprimido antes de ser enviado a través de la red. Esto supone que el tamaño de los datos enviados será mucho menor y por consiguiente la carga será más rápida. Hay que tener en cuenta que en ciertos servidores y ciertos tipos de web la activación de este sistema puede hacer que el uso de recursos en el servidor aumente así que conviene probarlo con cautela.

Para activarlo tendríais que añadir lo siguiente a vuestro fichero .htaccess, veréis que le decimos que sirva comprimidos los ficheros html, css y javascript:

# BEGIN GZIP
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
</ifmodule>
# END GZIP

Enlace al artículo anterior:

Optimización de WordPress: las cabeceras, fichero header.php

En esta serie de artículos intentaré ofrecer unos cuantos consejos para optimizar en la medida de lo posible aquellos blogs que utilizan WordPress.

Uno de los puntos flojos de WordPress es su excesivo uso de cpu, memoria y recursos de servidor en general, sobre todo con la inclusión de plugins, temas, etc. En este artículo vamos a empezar optimizando el fichero que genera la cabecera HTML del blog, header.php.

El objetivo de estos cambios es reducir el número de consultas MySQL y ejecución de llamadas PHP al servidor, haciendo lo más estática posible la cabecera de nuestro blog. Para ello, evitaremos que se llame a la base de datos para buscar el nombre del blog, la ubicación de los css, javascript o feed.

Lo primero que debemos hacer es encontrar el fichero header.php, que se encontrará en la carpeta del tema que usemos. Los temas están en la ruta “/wp-content/themes/”, en nuestro caso vamos a trabajar con un tema que se llama stardust, así que la ruta del fichero header.php es:

/wp-content/themes/stardust/header.php

Comenzamos con las modificaciones, empezamos configurando el título del blog de forma estática, eliminando la llamada php, que lo busca en la base de datos MySQL:

Antes:

<title><?php bloginfo('name'); ?><?php wp_title(); ?></title>

Después:

<title>Este es el título de mi blog</title>

Cambiamos también las declaraciones meta y el charset de la página, que siempre será igual (aunque no sepáis para que sirve, es seguro hacer este cambio):

Antes:

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Después:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

La siguiente línea la podemos eliminar directamente:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /> <!-- leave this for stats please -->

Las llamadas a las rutas de los ficheros de estilos css también podemos configurarlas directamente:

Antes:

<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_url'); ?>" media="screen" />

Después:

<link rel="stylesheet" type="text/css" href="/wp-content/themes/stardust/style.css" media="screen" />

Nota: Si no sabéis la ruta exacta al fichero css, podéis buscarlo por FTP (se llama style.css) dentro de la carpeta de vuestro tema o en el navegador pulsar Ctrl+U para ver el código fuente y buscar la línea anterior.

También podemos llamar de forma estática al fichero favicon.ico, que es el icono de favoritos y la página:

Antes:

<link rel="shortcut icon" href="<?php bloginfo('template_url'); ?>/favicon.ico" />

Después:

<link rel="shortcut icon" href="/wp-content/themes/stardust/favicon.ico" />

La URL para los pingback va a ser siempre la misma, con lo que también podemos modificara:

Antes:

<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />

Después (cambiad miblog.es por vuestro blog):

<link rel="pingback" href="http://miblog.es/xmlrpc.php" />

También podemos configurar como estáticas las rutas a los ficheros javascript que utilicemos en el blog. Esto depende de cada blog y la ruta en la que estén, para orientaros, será algo así:

Antes:

<script type="text/javascript" src="<?php bloginfo('template_url'); ?>/js/miscript.js"></script>

Después:

<script type="text/javascript" src="/wp-content/themes/stardust/js/miscript.js"></script>

Con estos cambios hemos reducido drásticamente las llamadas php/mysql al servidor y por consiguiente aligerado en gran medida la rapidez de carga de nuestra web y su uso de recursos. Hay que tener en cuenta que cada tema puede variar y tener diferentes llamadas php, es cuestión de retocar la cabecera investigando el fichero según sus necesidades.

En esta entrada vamos a instalar el servidor web Lighttpd con soporte para PHP a través de FastCGI. Lighttpd se caracteriza por ser un servidor web ligero y rápido a la vez que seguro y flexible.

Lo primer que hacemos es descargar la última versión estable de Lighttpd y descomprimirla:

# wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.28.tar.gz
# tar -xzvf lighttpd-1.4.28.tar.gz

Vamos a compilar Lighttpd, en este caso vamos a dejar las opciones por defecto y deshabilitar ipv6, zlib y bzip2, básicamente es para que veáis como siempre algun parámetro de la línea de compilación, podríais compilarlo como está por defecto sin problemas. Lo instalamos en la ruta /usr/local/lighttpd.

# mkdir /usr/local/lighttpd
# cd lighttpd-1.4.28
# ./configure --prefix=/usr/local/lighttpd --without-zlib --without-bzip2 --disable-ipv6

Al finalizar aparecerá un resumen de lo que vamos a instalar con las características y plugins activos/deshabilitados, ejemplo:

Plugins:

enabled:
  mod_access
  mod_accesslog
  mod_alias
  mod_auth
  mod_cgi
  mod_compress
  mod_dirlisting
  mod_evhost
  mod_expire
  mod_extforward
  mod_fastcgi
  mod_flv_streaming
  mod_indexfile
  mod_proxy
  mod_redirect
  mod_rewrite
  mod_rrdtool
  mod_scgi
  mod_secdownload
  mod_setenv
  mod_simple_vhost
  mod_ssi
  mod_staticfile
  mod_status
  mod_trigger_b4_dl
  mod_userdir
  mod_usertrack
  mod_webdav
disabled:
  mod_cml
  mod_magnet
  mod_mysql_vhost

Features:

enabled:
  auth-crypt
  large-files
  regex-conditionals
disabled:
  auth-ldap
  compress-bzip2
  compress-deflate
  compress-gzip
  network-ipv6
  network-openssl
  stat-cache-fam
  storage-gdbm
  storage-memcache
  webdav-locks
  webdav-properties

Si todo es correcto, compilamos e instalamos:

# make && make install

Vamos a crear un usuario/grupo dedicado para la ejecución del servicio, sin acceso shell:

# groupadd lighttpd
# useradd -g lighttpd -s /sbin/nologin -d /var/www/html lighttpd

Creamos la estructura de logs:

# mkdir /var/log/lighttpd && chown lighttpd:lighttpd /var/log/lighttpd

Para finalizar de momento con Lighttpd, creamos el fichero de configuración básico, lo podemos ubicar en /etc/lighttpd:

# mkdir /etc/lighttpd && cd /etc/lighttpd

Ahora podemos copiar el fichero de configuración básico que tenemos en las sources:

# cp ./doc/config/lighttpd.conf /etc/lighttpd/ && chown lighttpd:root /etc/lighttpd/lighttpd.conf

Está perfectamente documentado así que una vez personalizado con vuestros requerimientos (probablemente incluso dejandolo tal cual sea suficiente de momento) creamos el script para arrancar/parar el servicio en init.d:

cp ./doc/initscripts/rc.lighttpd.redhat /etc/init.d/lighttpd && chmod +x /etc/init.d/lighttpd

Si queréis, antes de seguir con PHP podéis arrancar el servicio y crear una página de test para verificar que funciona correctamente:

# /etc/init.d/lighttpd start

Ahora vamos a instalar PHP, si queréis información detallada sobre la compilación de PHP podéis ver este otro artículo en el que instalamos Apache y PHP, en este caso hacemos una compilación básica con todo por defecto de la versión 5.3.6:

# wget http://es2.php.net/get/php-5.3.6.tar.gz/from/ar2.php.net/mirror
# tar -xzvf php-5.3.6.tar.gz
# cd php-5.3.6
# ./configure
# make
# make install

Finalmente configuramos Lighttpd para usar PHP a través de FastCGI, añadimos lo siguiente al fichero de configuración lighttpd.conf para activar soporte FastCGI:

fastcgi.server = ( ".php" =>
                   ( "localhost" =>
                     ( "socket" => "/tmp/fcgi.socket",
                       "bin-path" => "/usr/local/bin/php-cgi"
                     )
                   )
                 )

Reiniciamos Lighttpd y ya deberíamos poder visualizar páginas php desde el servidor web:

# /etc/init.d/lighttpd restart

Kickstart/Anaconda permite realizar instalaciones desatendidas de sistemas CentOS (y por ende Red Hat y derivados) de modo que podamos instalar y configurar todos los equipos que queramos sin realizar la instalación uno a uno. Además podemos añadir tareas pre y post instalación para instalar software extra, realizar configuraciones, etc. Por supuesto esto es extremadamente útil para instalaciones masivas de sistemas.

Básicamente se tiene que crear un fichero (ks.cfg) en el cual se especifican las ordenes que tienen que realizarse en la instalación, esto incluye tanto los pasos de particionado como de configuración de red, paquetes, método de instalación, etc. Para aprender en profundidad las opciones que nos ofrece Anaconda y el fichero Kickstart os recomiendo encarecidamente leer la documentación oficial de Red Hat ya que aquí vamos a tratarlo por encima por ser demasiado extenso (hay incluso una GUI para hacerlo de forma gráfica).

Si necesitáis un fichero ks.cfg base, sabed que en cualquier sistema RHEL, CentOS cuando se termina la instalación automáticamente se guarda un fichero en /root/anaconda-ks.cfg que muestra como sería el fichero ks.cfg si quisieramos hacer una instalación igual de forma desatendida.

En este caso vamos a utilizar el siguiente ks.cfg, de nuevo os recomiendo leer la documentación de Red Hat citada anteriormente para saber personalizarlo al máximo:

install
cdrom
url --url http://ftp.udl.es/pub/centos/5.6/os/i386
lang en_US.UTF-8
keyboard es
network --device eth0 --bootproto static --ip 192.168.0.157 --netmask 255.255.255.0 --gateway 192.168.0.1 --nameserver 80.58.0.33 --hostname pruebacentos.com
rootpw --iscrypted $1$OarXPadVzGFPz3wjA0GwkkW3dp/ad/
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
selinux --disabled
timezone --utc Europe/Madrid
bootloader --location=mbr --driveorder=hda

clearpart --linux --drives=hda
part /boot --fstype ext3 --size=100 --ondisk=hda
part pv.2 --size=0 --grow --ondisk=hda
volgroup VolGroup00 --pesize=32768 pv.2
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=256 --grow --maxsize=512
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow

%packages
@core
%post
/usr/bin/yum -y update

Alguna particularidad de este ejemplo es que usamos la instalación desde un cdrom, que se trata de un netinstall y que descargamos la imagen desde FTP, que asignamos una IP estática, la clave de root, el particionado, únicamente instalamos el paquete base (@core) y que tras finalizar la instalación actualizamos el sistema con yum.

Existen varias formas de decirle a nuestra instalación que tiene que usar Kickstart, ya sea desde un Diskette, CD-ROM o desde la red. Esto podemos especificarlo en el momento del boot del instalador (boot prompt).

Instalación desde Diskette

linux ks=hd:fd0:/ks.cfg

Instalación desde CD

Especificamos la ruta directa en el CD al fichero Kickstart

linux ks=cdrom:/ks.cfg

Instalación desde red/url

En este caso tendríamos que tener un servidor DHCP que le asignara IP al equipo para poder acceder a la URL

linux ks=http://192.168.0.111/ks.cfg

De esta forma hay un problema, que tenemos que manualmente especificar la ruta al Kickstart en el boot prompt. El paso final para evitar esto es modificar la ISO de CentOS y especificar ahí este punto, de modo que no requiera intervención por nuestra parte en ningún punto.

Para ello, descargamos la ISO, en mi caso del NetInstall y la montamos como si fuera una ruta local:

# sudo mount -o loop -t iso9660 CentOS-5.6-i386-netinstall.iso /media/iso_centos

Ahora tenemos que modificar el fichero isolinux.cfg y modificar el boot así que copiamos todo a otra ruta (el CD se monta como solo lectura) y modificamos este fichero:

# cp -R /media/iso_centos/ /home/alex/

Ahora modificamos el fichero isolinux/isolinux.cfg y modificamos:

Antes:

label linux
  kernel vmlinuz
  append initrd=initrd.img

Después:

label linux
  kernel vmlinuz
  append initrd=initrd.img ks=cdrom:/isolinux/ks.cfg

En este caso copiaremos el fichero ks.cfg en la carpeta “isolinux”, y como luego lo quemaremos en un CD usamos la opción de cdrom. Si fuerais a cogerlo desde la red, en vez de cdrom ponéis la url del ks.cfg y solucionado.

Ahora solo nos quedaría hacer una nueva iso con nuestro netinstall modificado, podemos usar el comando mkisofs. Debemos especificarle el boot para que cree una ISO booteable:

cd /home/alex/iso_centos/ && mkisofs -o /home/alex/centos_5.6_kickstart.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-info-table -boot-load-size 4 -R -J -T .

Una vez que tenemos la iso creada solo falta grabarla a CD y arrancar con ella el servidor/PC, toda la instalación se debería hacer de forma automática y desatendida.

La controladora Smart Array E200i de HP, utilizada normalmente en servidores HP Proliant DL360 para discos SAS, no permite la migración de un RAID 0 a RAID 1+0 sin perdida de datos ni de disponibilidad a no ser que añadamos a la controladora el kit BBWC (battery backed cache upgrade), la cual también permite la creación de RAID 5.

Suponemos entonces que tenemos el hardware necesario y que la configuración de discos es la siguiente:

• 1 disco en RAID 0.
• 1 disco sin asignar.

Lo primero que tendremos que hacer es tener instalado ACU (Utilidad de Configuración de Arrays) y HP System Management. Podéis descargar ambos e instalarlos desde los CD support pack de HP o desde el sitio web. Su instalación es sencilla, en caso de RHEL o CentOS es via RPM.

Una vez instalado, arrancamos en el servidor ambos servicios:

# /usr/sbin/cpqacuxe -R
# /etc/init.d/hpsmhd restart

Bien, entrando al tema, tenemos que acceder a la interfaz web de HPSM, usando la IP o hostname de la máquina y el puerto 2381 (y via HTTPS):

https://192.168.0.222:2381/

Accedemos al ACU, Array Configuration Utility y seleccionamos la controladora:

Una vez dentro, seleccionamos el array/unidad lógica que queremos modificar, en ese caso el array SAS , si la battery backed cache está correctamente instalada y cargada debería aparecer a la derecha la opción “Expandir Array“. También veremos la unidad/disco sin asignar:

Tras pinchar en “Expandir Array” veremos que aparece ya la posibilidad de añadir el disco sin asignar al array:

Guardamos los cambios y automáticamente veremos el % de progreso de la transformación del RAID:

Una vez que finalice, ya tenemos el nuevo disco asignado a la unidad lógica. Llega el momento entonces de migrar el RAID:

Tras pinchar ya tendremos la opción de migrar a RAID 1. Automáticamente se seleccionará el Full stripe size de 128K
 

 

Ya solo queda esperar a que termine la migración de RAID 0 a RAID 1+0. Hemos conseguido realizarlo sin parada de servicio ni perder ningún dato del anterior RAID 0.

Hace unas semanas que se publicó la esperada versión BETA de Red Hat Enterprise Linux 6 (RHEL). Vamos a usar dicha versión para hacer una guía del proceso de instalación. Para todos aquellos interesados, ya se puede descargar la ISO desde el sitio FTP de Red Hat:

ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/i386/iso/

Comenzamos en la pantalla de inicio, en la cual podemos seleccionar comenzar una instalación nueva, actualizar el sistema, arrancar en modo de rescate y arrancar con el disco local. Usando la tecla [TAB] podemos modificar las opciones de arranque de cada modo para personalizarlo (añadir drivers extra, instalación en modo texto, etc).

En este caso vamos a hacer la instalación sin realizar ninguna modificación, así que seleccionamos la primera opción.

Seleccionamos el idioma que será usado para el proceso de instalación, personalmente me gusta utilizar siempre inglés

Seleccionamos el tipo de teclado (es).

Elegimos el medio a través del cual hacemos la instalación, en este caso la hacemos localmente desde el CD/DVD, aunque como ya hicimos en otras instalaciones (Por ejemplo CentOS 5) podemos usar un FTP remoto, URL o directorio NFS.

Saltamos la verificación del DVD y comenzamos la instalación:

Entramos en la instalación en modo texto, en mi caso ha sido forzado a que la máquina virtual no tenía suficiente memoria RAM para ejecutar el modo gráfico, no obstante el proceso es prácticamente idéntico (por defecto saldrá el entorno gráfico).

En primera instancia tenemos que inicializar los discos duros en caso de ser nuevos, hay que tener en cuenta que se eliminará cualquier dato que haya en ellos. Si hicierais la instalación sobre un disco con otro sistema ya instalado, por ejemplo CentOS, Fedora, etc os avisaría sobre ello y daría opción de reinstalarlo, eliminarlo o compartir el disco entre ambos sistemas:

Una vez inicializado el disco, seleccionamos la zona horaria:

Configuramos la clave para el usuario root:

Comenzamos el particionado del disco, podemos elegir usar el disco completo, reemplazar el sistema operativo anterior o utilizar únicamente el espacio libre. En nuestro caso usamos el disco completo ya que no tenemos nada más instalado. Si utilizamos la primera opción la instalación creará el particionado estándar con las otras opciones podremos personalizarlo. Fijaos que ya podemos seleccionar EXT4 como sistema de ficheros (por defecto):

Una vez realizado el particionado, comenzará la instalación de los paquetes  básicos y el sistema base:

Ya tenemos instalado nuestro sistema Red Hat Enterprise Linux 6 Beta, como veis ha sido realmente sencillo. Algo que me ha llamado la atención es que no haya tenido la opción de seleccionar paquetes y aplicaciones extra en este proceso de instalación, algo que siempre hemos podido hacer en CentOS y RHEL anteriores. Quizás sea por ser la versión beta, no obstante, si apareciera dicha opción en la instalación gráfica podríamos elegir entre distintos servicios y aplicaciones para instalar, también suelen permitir configurar las tarjetas de red, algo que en este caso no me ha sido solicitado tampoco.

Squid es un popular programa de software libre que implementa un servidor proxy y un dominio para caché de páginas web, publicado bajo licencia GPL. Tiene una amplia variedad de utilidades, desde acelerar un servidor web, guardando en caché peticiones repetidas a DNS y otras búsquedas para un grupo de gente que comparte recursos de la red, hasta caché de web, además de añadir seguridad filtrando el tráfico. Está especialmente diseñado para ejecutarse bajo entornos tipo Unix.                                                                                               Definición Wikipedia.

Vamos a instalar Squid en un servidor CentOS y posteriormente configurar los navegadores web (Firefox y Chrome) para que utilicen este proxy para la navegación.

Instalación Proxy Squid en CentOS

Podemos elegir la opción de compilar a mano o instalarlo a través de yum, elegimos por comodidad la segunda opción:

# yum install squid

Configuramos squid para que arranque automáticamente y arrancamos el proxy:

# chkconfig squid on
# /etc/init.d/squid start

Ahora debemos asegurarnos que el puerto TCP utilizado por squid está abierto en el firewall, el puerto es el TCP 3128:

tcp        0      0 0.0.0.0:3128                0.0.0.0:*                   LISTEN

En CentOS el fichero de configuración de Squid se encuentra en “/etc/squid/squid.conf“, por defecto veréis que hay una configuración estandar de acl y puertos permitidos que podéis modificar como queráis:

#Recommended minimum configuration:
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http

acl CONNECT method CONNECT

Debemos configurar el proxy para permitir acceso a un determinado rango de IPs, en este caso lo abrimos para todo el mundo, podéis ver como he comentado “http_access deny all” y añadido “http_access allow all“, esto se configura según los requerimientos de cada uno:

# Example rule allowing access from your local networks. Adapt
# to list your (internal) IP networks from where browsing should
# be allowed
#acl our_networks src 192.168.1.0/24 192.168.2.0/24
#http_access allow our_networks

# And finally deny all other access to this proxy
http_access allow all
#http_access deny all

Esta es la configuración más básica, reiniciamos Squid y ya podemos comenzar a configurarlo en el navegador de nuestro PC. Recomiendo leer detenidamente el fichero de configuración, cuenta con buenas explicaciones de cada uno de los parámetros.

Configurar Proxy Squid en Firefox

Para configurar nuestro navegador Firefox para que navegue a través del proxy, haremos lo siguiente:

Menú editar —> preferencias —> red —> configuración —> Configuración manual del proxy….

Los parámetros a configurar son:

PROXY HTTP: IP del proxy
Puerto: 3128

Marcamos la casilla “usar proxy para todos los puertos” si deseamos usar el proxy para todo.

Configurar Proxy Squid en Google Chrome

Preferencias —> Avanzadas –> Cambiar la configuración del proxy —> Configuración manual del proxy

PROXY HTTP: IP del proxy
Puerto: 3128

Marcamos la casilla “usar proxy para todos los puertos” si deseamos usar el proxy para todo.

Con este sencillo tutorial ya deberíamos poder navegar por Internet desde el proxy Squid en nuestros navegadores.