Menú de la documentación

Opciones de caché y solución de problemas

Las opciones de caché son una secuencia final en la contraseña del proxy. Las opciones del nombre de usuario, como el pool, el país, la ciudad y la sesión, no cambian. El sufijo es la activación completa: Litport no activa la caché en silencio para un token, y una solicitud sin él sigue siendo una solicitud de proxy normal.

PASSWORD_cache-<types>[_cacheduration-<minutes>][_cacheignoreheader-1]

Ejemplos:

username:password_cache-images,fonts
username_country-us_sid-crawl-42:password_cache-all_cacheduration-30
username:password_cache-scripts_cacheduration-60_cacheignoreheader-1

Litport prueba primero la contraseña completa tal cual. Así se conserva una contraseña existente que casualmente termina con un texto parecido a un sufijo de caché. Solo cuando esa credencial exacta no existe, Litport analiza una secuencia final de caché válida y autentica la contraseña base.

Opciones#

Opción Valores Comportamiento
_cache- images, scripts, fonts, all, una extensión admitida o una mezcla separada por comas Activa los tipos elegibles. Los valores no distinguen mayúsculas de minúsculas; los valores generados van en minúsculas.
_cacheduration- Minutos enteros, mínimo 1 Por defecto es 120 cuando falta o es menor que 1. La expulsión operativa puede quitar una entrada antes.
_cacheignoreheader-1 1 literal Ignora las directivas de frescura y privacidad del origen en respuestas que por lo demás son elegibles. Su TTL solicitado empieza cuando Litport recibe y almacena la respuesta completa; el Date y el Age del origen no se restan de él. Siguen aplicándose las exclusiones de seguridad absolutas.

Las extensiones son png,jpg,jpeg,gif,svg,ico,webp, js,css,wasm,map y woff,woff2,ttf,eot,otf. Una lista vacía o un valor no admitido deja la solicitud sin caché sin afectar la autenticación del proxy.

Resultado de la solicitud#

¿GET HTTPS elegible?Tipo de archivo seleccionado, solicitud segura, modo de caché habilitado
AciertoServir el cuerpo localBytes en caché gratis
FalloObtener del origen verificadoCobro normal; almacenar si admite caché
OmisiónInseguro o no almacenable en cachéProxy y cobro normales
Cada solicitud en modo de caché termina en un acierto, un fallo o una omisión. Solo son gratis los bytes entregados realmente desde un cuerpo en caché.
  • Acierto: los bytes del cuerpo de la respuesta entregados desde la entrada del hub son gratis. Una interrupción del cliente o un error de lectura de la caché siguen apareciendo en el estado de entrega y nunca pasan a tráfico con cobro.
  • Fallo: Litport abre la ruta upstream normal. Los bytes de la solicitud y de la respuesta se cobran normalmente. Una respuesta completa y válida puede almacenarse para otra solicitud.
  • Omisión: Litport envía la solicitud al upstream sin usar ni almacenar una entrada de caché. El tráfico se cobra normalmente.

No existe un encabezado de respuesta propio o autoritativo de Litport que indique un acierto de caché. Age puede aparecer o aumentar en una respuesta en caché, pero los orígenes y las CDN también pueden establecerlo; usa Estadísticas de tráfico o la API de tokens para consultar aciertos, fallos, omisiones, bytes gratis y ahorro en pago por GB. No hay purga manual.

Elegibilidad y exclusiones absolutas#

Litport solo almacena respuestas GET HTTPS con estado 200 y una ruta que termina en una extensión seleccionada. La URL exacta, incluidos el orden y la codificación de la consulta, identifica el objeto. En modo estándar, s-maxage prevalece sobre max-age; gana el menor entre la frescura válida del origen y la duración solicitada. La duración solicitada es un máximo estricto: cuando una respuesta del origen en modo estándar ya tiene un Age corregido igual o superior a ella, Litport no almacena esa respuesta. Con _cacheignoreheader-1, el TTL solicitado empieza cuando Litport recibe y almacena la respuesta completa, sin restar el Date ni el Age del origen.

Estas solicitudes siempre omiten la caché, incluso con _cacheignoreheader-1:

  • Authorization, Cookie, Range o encabezados de solicitud condicionales
  • Cache-Control: no-cache, no-store o max-age=0, o Pragma: no-cache, en la solicitud
  • Set-Cookie, Vary no admitido, contenido parcial, respuestas demasiado grandes o cuerpos incompletos
  • service workers, URL sin extensión, API, documentos, video, audio y archivos comprimidos
  • destinos http:// sin cifrar, entrada SOCKS5, UDP y HTTP/3/QUIC

_cacheignoreheader-1 puede anular directivas de caché de la respuesta que faltan o que bloquean, pero no la lista anterior. Como una entrada almacenada se comparte en un hub, usa esta opción solo para recursos públicos sin autenticación que sean idénticos para cualquier solicitante.

Comportamiento de los protocolos#

Para las solicitudes HTTPS en modo de caché se admiten clientes HTTP/1.1 y HTTP/2. Litport también puede negociar HTTP/2 en el tramo verificado hacia el origen. HTTP/3 usa QUIC sobre UDP, mientras que la ruta explícita del proxy HTTP de Litport es TCP CONNECT; por eso la solicitud QUIC no entra en esta ruta de caché. Las aplicaciones suelen recurrir a HTTP/2, pero Litport no afirma que haya caché para HTTP/3.

El endpoint del proxy de Litport puede escribirse como http://HUB:PORT. La elegibilidad se basa en la URL de destino, que debe ser https://....

Solución de problemas#

Síntoma Motivo probable Qué hacer
Error de emisor TLS o de CA desconocida El proceso del cliente no confía en la raíz de Litport Configura la CA en ese proceso; verifica la huella descargada.
Funciona sin _cache-, falla con él Almacén de confianza propio de la aplicación o fijación de certificados (pinning) Configura la aplicación si es tuya, o no uses el modo de caché. La fijación de certificados de terceros no se puede eludir.
Se cobra la primera solicitud El hub seleccionado está en frío Repite la misma URL elegible a través del mismo hub.
Las solicitudes volvieron a estar en frío tras cambiar de hub El almacenamiento de la caché es local, no se replica Precalienta el nuevo hub o usa un solo hub para esa carga de trabajo.
Todas las solicitudes son un fallo La URL o la consulta difiere, la entrada caducó o fue expulsada, o la respuesta no se puede almacenar Compara las URL exactas e inspecciona los encabezados de caché y el estado del origen.
Una respuesta del origen que parece fresca no se almacena en modo estándar Su Age corregido ya es igual o superior a la duración solicitada Solicita una duración mayor cuando corresponda, usa una respuesta con frescura restante o usa la anulación avanzada solo para recursos públicos sin autenticación.
Una respuesta en caché está obsoleta o debe cambiar de inmediato No hay purga manual Usa un TTL más corto o URL con versión y espera a que caduque la entrada.
La solicitud es una omisión Se excluye el método, los encabezados, la respuesta, el esquema de destino, la entrada o la extensión Usa un GET HTTPS público elegible o sigue con el proxy normal con cobro.
HTTP sin cifrar nunca se almacena en caché Su tramo hacia el origen no tiene integridad autenticada Sigue usándolo con normalidad; una CA no puede hacer elegible el HTTP sin cifrar.

Para destinos sensibles al transporte, lee Caché y huellas de transporte.