Aunque el blog ahora está ubicado en el host VPS CN2 de Alibaba Cloud Hong Kong, Telecom usa la línea CN2, por lo que la velocidad de acceso será más rápida (pero también recibí comentarios de amigos de Telecom de que el acceso es lento (⊙﹏⊙)) . Sin embargo, China Unicom y los usuarios de dispositivos móviles tendrán un acceso más lento, especialmente durante el período pico de la tarde. Muchos amigos dijeron que no pueden abrirlo en absoluto.

A juzgar por el anuncio oficial, Alibaba Cloud Hong Kong CN2 VPS de hecho ha encontrado problemas con las líneas China Unicom o los nodos de líneas de telecomunicaciones, lo que ha provocado problemas de acceso a toda la sala de ordenadores. Por supuesto, Alibaba Cloud, naturalmente, dejará el "bote" a los operadores. Hace algún tiempo, los usuarios de China Unicom tuvieron que pasar por alto Japón u otros lugares para acceder al VPS de Alibaba Cloud Hong Kong.

Cuando me mudé de Kdatacenter Korea VPS a Alibaba Cloud Hong Kong VPS, en primer lugar, sentí que Alibaba Cloud Hong Kong VPS era bastante barato y atractivo; en segundo lugar, sentí que la línea CN2 podría ser buena, al menos mucho más rápida que la estadounidense; línea. Ahora parece que, salvo para los usuarios de telecomunicaciones, el acceso será más fluido, mientras que los usuarios de otros operadores tendrán problemas de vez en cuando.

Para resolver este problema, lo natural es acelerar la CDN del sitio web. Naturalmente, el VPS nacional no se puede utilizar sin un número BA, por lo que encontré un método VPS coreano que utiliza el proxy inverso Nginx para transferir las solicitudes de acceso de los usuarios de China Mobile y China Unicom al servidor CDN, lo que puede maximizar la velocidad de acceso al sitio web.

Aceleración de CDN autoconstruida: enlace inverso de Nginx, aceleración de caché, actualización automática de caché y obtención de IP real

Este artículo explicará en detalle cómo crear una CDN para que el sitio web acelere y almacene en caché las páginas y archivos correspondientes. Al mismo tiempo, cuando se actualice el contenido del sitio web, use ngx_cache_purge para actualizar rápidamente el caché en el servidor CDN. resolver el problema de la adquisición del servidor de origen durante el uso. El problema de la IP real del usuario. Más herramientas de aceleración de CDN y creación de sitios web incluyen:

  1. Únase a Cloudflare Partner para proporcionar el servicio de aceleración CDN de CloudFlare de forma gratuita: no es necesario modificar NS para admitir SSL
  2. Utilice Fikker para crear su propia CDN: admite HTTPS, almacenamiento en caché de páginas, monitoreo en tiempo real, estadísticas de tráfico y prevención de ataques CC
  3. Dos excelentes herramientas de monitoreo del tráfico de la red del servidor: Ntopng y Munin: potentes e intuitivas

PD: Actualizado el 27 de abril de 2018. Actualmente, Youpaiyun CDN se utiliza para imágenes y archivos estáticos como JS y CSS en el sitio web. Artículo de revisión: Tutorial de uso y aplicación acelerada de Youpaiyun CDN-1 Duplicación de claves. CDN dinámico estático y SSL gratuito.

PD: Actualizado el 6 de marzo de 2018, Si no desea crear una CDN usted mismo, puede probar un servicio de aceleración de CDN de terceros. El conocido CloudFlare es una muy buena opción: diez cosas. Es posible que no conozca el consejo de aceleración de CDN gratuito de CloudFlare: SSLDDOSCache.

1. Instale Nginx

Puede instalar y configurar Nginx manualmente, o usar el paquete de instalación de un clic de LNMP para instalar Nginx. Los más útiles son: Oneinstack y LNMP. Si no desea usarlo, puede probar el paquete de instalación Nginx con un solo clic de xiaoz (aplicable a Centos 7 y Deebian 8).

  1. https://GitHub.com/hellonow/nginx-cdn

Linux instala Nginx con un clic y activa CDN (proxy inverso). Simplemente ejecute el siguiente comando para instalarlo.

wget https://raw.githubusercontent.com/helloxz/nginx-cdn/master/nginx.sh
chmod +x nginx.sh && ./nginx.sh

2. Configuración relacionada con Nginx

Aquí uso wzfou.com como ejemplo para la aceleración. Hay un VPS de origen y un VPS utilizado como proxy inverso de CDN. Las IP correspondientes de los dos son las siguientes:

1. Sitio de origen: 192.168.1.100, que es donde realmente se almacenan los datos del sitio web wzfou.com.

2. CDN: 192.168.1.101   nodo CDN, si hay varios nodos CDN, el método de operación es el mismo

Primero modifique los Hosts en el nodo CDN. El propósito es decirle al nodo CDN dónde obtener los datos del sitio web, es decir, la dirección de retorno a la fuente.


vi /etc/hosts
192.168.1.100	www.wzfou.com

Luego cree el archivo de configuración de nginx wzfou.com.conf en el nodo CDN

#创建缓存目录
mkdir -p /data/wwwroot/caches/wzfou.com
#设置缓存目录权限
chown -R www:www /data/wwwroot/caches/wzfou.com
#创建wzfou.com.conf
vi /usr/local/nginx/conf/vhost/wzfou.com.conf

Agregue el siguiente contenido a wzfou.com.conf. Ajuste el directorio de caché/tiempo de caché de acuerdo con la situación real. El significado de cada parámetro se explicará en detalle más adelante.

proxy_cache_path /data/wwwroot/caches/wzfou.com levels=1:2 keys_zone=wzfou:50m inactive=30m max_size=50m;
server {
    listen 80;
    server_name wzfou.com;
    charset utf-8,gbk;
        location / {
        proxy_set_header Accept-Encoding "";
           proxy_pass https://wzfou.com;
           proxy_redirect off;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_cache wzfou;
           proxy_cache_valid  200 304  30m;
           proxy_cache_valid  301 24h;
           proxy_cache_valid  500 502 503 504 0s;
           proxy_cache_valid any 1s;
           proxy_cache_min_uses 1;
           expires 12h;
    }
}

Las instrucciones relevantes son las siguientes:

1. /data/wwwroot/caches/wzfou.com: es el directorio de caché

2. niveles: especifique que el espacio de caché tiene dos niveles de directorios hash, el directorio del primer nivel es de 1 letra y el segundo nivel es de 2 letras.

3. keys_zone=wzfou:50m: Asigne un nombre al espacio de caché, aquí se llama "wzfou", y los siguientes 50 m se refieren al espacio de memoria caché.

4. inactive=30m: si no se accede al recurso en 30 minutos, se eliminará.

5. max_size=50m: se refiere al tamaño de caché del disco duro de 50 MB

6. proxy_cache_valid: especifique el tiempo de caché del código de estado en el frente y el tiempo de caché en la parte posterior.

Finalmente, vuelva a cargar nginx para que la configuración surta efecto. Si está utilizando oneinstack, ingrese el comando directamente: service nginx reload. Si es el script de un clic de xiaoz, ingrese: /usr/local. /nginx/sbin/nginx -s recargar .  

3. Proxy inverso del sitio HTTPS

Lo que se comparte arriba es la configuración del proxy inverso de Nginx para el sitio HTTP. Si desea realizar el proxy inverso del sitio HTTPS, primero debe solicitar el certificado SSL para su nombre de dominio y luego solo necesita. para configurarlo. Para obtener una buena ruta de certificado SSL, consulte la siguiente configuración para ajustarlo:

proxy_cache_path /data/wwwroot/caches/wzfou.com levels=1:2 keys_zone=wzfou:50m inactive=30m max_size=50m;
server {
  	listen 443 ssl http2;
	ssl_certificate	/data/ssl/wzfou/wzfou.com.crt;
	ssl_certificate_key	/data/ssl/wzfou/wzfou.com.key;
	ssl_session_timeout 1d;
	ssl_session_cache builtin:1000 shared:SSL:10m;
    #ssl_dhparam /data/ssl/dhparam.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;


    ssl_stapling on;
    ssl_stapling_verify on;

    server_name wzfou.com;
    access_log /data/wwwlogs/wzfou.com_nginx.log combined;
   
    charset utf-8,gbk;
        location / {
        proxy_set_header Accept-Encoding "";
           proxy_pass https://wzfou.com;
           proxy_redirect off;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_cache wzfou;
           proxy_cache_valid  200 304  30m;
           proxy_cache_valid  301 24h;
           proxy_cache_valid  500 502 503 504 0s;
           proxy_cache_valid any 1s;
           proxy_cache_min_uses 1;
           expires 12h;
    }
}
server {
    listen 80 default_server;
    return 301 https://$host$request_uri;
}

4. ngx_cache_purge borra el caché de actualización

La limpieza del caché de Nginx requiere la ayuda del módulo ngx_cache_purge. Puede ingresar el comando nginx -V para ver los módulos compilados. Si no hay ngx_cache_purge, significa que el módulo está. no está instalado y necesita volver a compilar Nginx.

4.1  Configurar ngx_cache_purge

Agregue la siguiente configuración a la sección del servidor y vuelva a cargar Nginx. Mantenga el siguiente wzfou coherente con el valor definido por keys_zone; de lo contrario, nginx no se iniciará.

location ~ /purge(/.*) {
allow all;
proxy_cache_purge wzfou $proxy_host$1$is_args$args;
error_page 405 =200 /purge$1;
}

Si desea borrar el caché, simplemente agregue el parámetro purge, como https://www.xiaoz.me/purge/xxx.png. caché, se le solicitará la siguiente captura de pantalla. Si no hay caché, se devolverá 404. Si se devuelve 404 pase lo que pase, es posible que la configuración no se realice correctamente.

4.2  WordPress actualiza automáticamente el caché

Para los blogs de WordPress, si la página se almacena en caché después de habilitar CDN y no se puede mostrar inmediatamente después de que el usuario envía un comentario, puede usar la interfaz de solicitud asíncrona Ajax ngx_cache_purge para borrar el caché de la página cuando el usuario envía un comentario. Simplemente agregue el siguiente js a footer.php.

<script>
		$(document).ready(function(){
			$("#submit").click(function(){
				var uri = "https://wzfou.com/purge" + window.location.pathname;
				$.get(uri,function(data,status){
					return true;
				});
			});
		});
	</script>

La siguiente es la configuración completa de Xiaoz Blog CDN, solo como referencia. Debe reemplazar Keys_zone, ruta SSL, nombre de dominio, etc.:

proxy_cache_path /data/caches levels=1:2 keys_zone=xiaozcdn:100m inactive=30m max_size=100m;
server
    {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl on;
    ssl_certificate /xxx/www_xiaoz_me.crt;
    ssl_certificate_key /xxx/www_xiaoz_me.key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    ssl_stapling_verify on;

    server_name     www.xiaoz.me;
    charset utf-8,gbk;

   #删除缓存
    location ~ /dcache(/.*) {
    allow all;
    proxy_cache_purge xiaozcdn $proxy_host$1$is_args$args;
    error_page 405 =200 /purge$1;
    }

       location / {
       #proxy_set_header Accept-Encoding "";
       proxy_pass https://www.xiaoz.me;
       proxy_redirect off;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_cache xiaozcdn;
       proxy_cache_valid  200 304  30m;
       proxy_cache_valid  301 24h;
       proxy_cache_valid  500 502 503 504 0s;
       proxy_cache_valid any 1s;
       #达到第几次被缓存?
       proxy_cache_min_uses 1;
       expires 12h;
       proxy_cache_key    $uri$is_args$args;
    }
}
server
{
    listen 80;
    server_name www.xiaoz.me;
    rewrite ^(.*) https://www.xiaoz.me$1 permanent;
}

5. Haga un buen trabajo en la resolución de nombres de dominio DNS

Utilizando las funciones de resolución de DNS, como líneas, regiones y clientes proporcionadas por la resolución de nombres de dominio DNS, podemos resolver diferentes usuarios de banda ancha, usuarios provinciales y usuarios de clientes en nodos CDN.

Utilice la prueba de la herramienta para webmasters para ver que los usuarios de diferentes lugares en wzfou.com acceden a diferentes nodos CDN, lo que significa que nuestra implementación de aceleración de CDN es exitosa.

6. No se puede obtener una IP real después de habilitar CDN

Si es un usuario de WordPress, cuando habilita la aceleración CDN de Nginx, encontrará que las IP de comentarios de usuario obtenidas por el backend de WP se han convertido en nodos CDN. Resolver este problema también es muy simple: solo necesita agregar el siguiente código a wp. - En el archivo config.php:

if (isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}

7. Resumen

Nginx vincula de forma inversa los nombres de dominio para crear un servidor de aceleración CDN con una instalación y configuración sencillas y de bajo costo. Es especialmente adecuado para amigos que no desean utilizar un CDN pago. De hecho, muchas aceleraciones CDN profesionales también utilizan el proxy inverso de Nginx para acelerar. Acceso al sitio web Se puede decir que Nginx CDN es un método de aceleración muy eficaz.

Hay dos problemas a los que se debe prestar atención al utilizar la aceleración CDN de Nginx. Uno es el problema de la actualización de la caché. Si su página web se actualiza con frecuencia, puede establecer un intervalo de tiempo de actualización. El segundo es el problema de la IP real del usuario. Podemos usar PHP o Nginx, etc. para obtener directamente la dirección IP real.

Deja una respuesta