Proxies y webhooks: por qué un proxy de salida no hace que tu servicio sea accesible desde afuera
Contenido del artículo
- Fundamentos: qué es realmente un proxy y qué es un webhook
- Dirección de la conexión: saliente contra entrante
- Por qué un proxy cliente no escucha un puerto ni da una dirección pública
- Redes móviles y dirección compartida: por qué una dirección de abonado no se puede direccionar desde afuera
- Qué resuelve realmente la tarea de recibir webhooks
- Sondeo como reemplazo del webhook: cómo diseñarlo para no chocar con los límites
- Dónde el proxy sí es necesario junto a los webhooks
- Errores típicos y cómo evitarlos
- Herramientas y recursos
- Casos y resultados
- Tabla: tarea y solución adecuada
- Faq: preguntas frecuentes
- Conclusión: juntemos todo
Existe una idea equivocada muy persistente que aparece una y otra vez en los chats de desarrolladores, entre los integradores de sistemas de pago y entre quienes se topan por primera vez con APIs externas. Suena más o menos así: "Compro un proxy y a ese proxy le llegará el webhook". La expectativa es comprensible, casi intuitiva. Si el proxy me da una dirección, entonces a esa dirección se puede llegar, ¿verdad? Lamentablemente, no. Y este error les cuesta a las personas horas de depuración, reportes de bugs falsos al proveedor y plazos incumplidos.
En esta guía vamos a desmenuzar el tema hasta la raíz. Por qué un proxy se desempeña perfectamente en la tarea de solicitudes salientes, pero es fundamentalmente incapaz de hacer que tu servicio sea accesible desde afuera. Qué ocurre a nivel de la dirección de la conexión. Por qué una dirección de abonado en una red móvil es imposible de direccionar desde afuera. Y lo más importante: qué usar realmente si necesitas recibir webhooks: un servidor con dirección pública, un túnel inverso, una cola del lado del proveedor o sondeo en lugar de suscripción.
El material está escrito con lenguaje de ingeniería, con ejemplos de código y marcos de decisión listos para usar. A propósito no describimos la configuración de routers ni el reenvío de puertos: ese es un tema vecino y solo vamos a delimitar su frontera. Nuestra tarea es otra: entender el modelo y elegir la herramienta correcta. Vamos.
Fundamentos: qué es realmente un proxy y qué es un webhook
Antes de discutir qué puede y qué no puede hacer un proxy, pongámonos de acuerdo en los términos. Sin eso, la conversación se convierte en un revoltijo de expectativas y mitos.
Proxy en palabras simples
Un servidor proxy es un intermediario para tus solicitudes salientes. Tu programa quiere comunicarse con algún sitio o API. En lugar de conectarse directamente, se conecta al proxy, y el proxy va a destino en su propio nombre y te devuelve la respuesta. La palabra clave aquí es saliente. El iniciador siempre eres tú.
Qué obtienes al usar un proxy:
- El servidor de destino ve la dirección IP del proxy, no la tuya propia.
- Puedes controlar la geografía y el tipo de red de salida (por ejemplo, móvil).
- Puedes distribuir la carga y rotar direcciones para tareas legales como la recolección de datos públicos o el testeo de contenido dependiente de la geografía.
Qué NO te da un proxy: no abre un puerto que escuche conexiones entrantes de terceros, ni convierte tu máquina en un servidor públicamente direccionable. Esto es fundamental. Lo guardamos y volvemos sobre ello.
Webhook en palabras simples
Un webhook es un mecanismo de llamada inversa. Registras una URL en un servicio de terceros y, cuando ocurre un evento (llegó un pago, cambió el estado de un pedido, se actualizó un documento), el servicio mismo inicia una solicitud HTTP a esa URL. Es decir, el servicio externo se convierte en cliente, y tú debes ser el servidor que escucha y responde.
Fíjate en la inversión de roles. En el caso del proxy, tú eres el cliente que toca a la puerta hacia afuera. En el caso del webhook, el mundo exterior es el cliente que toca a tu puerta. Son dos direcciones opuestas. Y justo aquí nace la confusión.
Por qué se confunden
Ambos conceptos están relacionados con las palabras "HTTP", "dirección", "solicitud". Una persona escucha "el proxy me da una IP" y saca una conclusión lógica pero incorrecta: si hay una IP, se le puede enviar un webhook. El problema es que tener una dirección IP de salida y tener un puerto escuchando públicamente son cosas distintas. La analogía: tienes el número de teléfono de una central de taxis, al que llamas para pedir un auto. Pero eso no significa que cualquiera pueda llamarte a ti a ese número y llegar exactamente a ti. El número pertenece a la central, no a ti.
Dirección de la conexión: saliente contra entrante
Esta es la idea central de todo el artículo. Si solo vas a retener una sección, que sea esta.
Quién toca a la puerta de quién
Toda conexión TCP tiene un iniciador y un lado receptor. El iniciador abre la conexión (hace connect), el lado receptor la escucha (hace listen y accept). Veamos dos esquemas.
Esquema de solicitud saliente a través de un proxy
Imaginemos la cadena en palabras, como una ruta de flechas:
- Tu aplicación (iniciador) → abre conexión hacia → el servidor proxy de Proxeon.
- El servidor proxy (ahora es el iniciador) → abre conexión hacia → la API de destino.
- La respuesta vuelve por el mismo camino a través de la conexión ya abierta.
Nota: ambas conexiones se inician desde adentro hacia afuera. Nadie desde afuera inicia la comunicación contigo. Siempre eres tú el primero en tocar la puerta. El proxy encaja perfectamente en este modelo, porque para las solicitudes salientes basta con saber abrir conexiones, no con recibirlas.
Esquema de webhook entrante
Ahora otra historia:
- El servicio externo (iniciador) → quiere abrir conexión hacia → tu servicio.
- Para eso necesita una dirección y un puerto públicamente alcanzables, donde alguien haga listen y accept.
- Tu servicio acepta la conexión, lee el cuerpo de la solicitud, responde con estado 200.
Aquí el iniciador está afuera. Eso significa que necesitas un punto alcanzable desde internet. Un proxy que funciona en modo cliente para tus solicitudes salientes no es ese punto. No escucha conexiones entrantes desde servicios ajenos hacia ti.
Por qué la dirección no se puede "invertir" por sí sola
A veces preguntan: ¿y no se puede simplemente "girar" el proxy para que reciba? Técnicamente, invertir la dirección es posible, pero eso ya sería un producto y una arquitectura completamente distintos: un proxy inverso, un túnel o un servidor. Un proxy cliente común para tráfico saliente no se convierte en receptor de conexiones entrantes con solo apretar un botón. Es como pedirle a una escalera que funcione como escalera mecánica en la dirección contraria: ambos tienen que ver con escalones, pero el mecanismo es distinto.
Por qué un proxy cliente no escucha un puerto ni da una dirección pública
Profundicemos en la mecánica técnica. Por qué precisamente un proxy cliente no puede ser un punto de recepción.
Proxy cliente y servidor proxy: no confundir los roles
Cuando "compras un proxy", obtienes acceso a un servidor proxy: dirección, puerto, usuario y contraseña. Tu aplicación actúa como cliente proxy: se conecta al servidor y le pide que redirija las solicitudes salientes. El puerto que indicas en la configuración es el puerto del servidor proxy al que te conectas tú, no el puerto donde alguien escuchará webhooks dirigidos a ti.
Veámoslo con un ejemplo de una solicitud común a través de un proxy en Python:
import requests
proxies = {
"http": "http://user:pass@gateway.proxeon.net:8080",
"https": "http://user:pass@gateway.proxeon.net:8080",
}
resp = requests.get("https://api.example.com/v1/orders", proxies=proxies, timeout=15)
print(resp.status_code, resp.json())Aquí todo es saliente. Tu código inicia la conexión con el proxy, el proxy va hacia api.example.com. No aparece ni puede aparecer ningún socket escuchando para recibir webhooks. El puerto 8080 pertenece a la infraestructura de Proxeon y está destinado a recibir tus solicitudes salientes, no a recibir webhooks ajenos dirigidos hacia ti.
Qué significa "escuchar un puerto" y por qué es una función aparte
Para recibir conexiones entrantes hace falta un proceso que haya ejecutado las llamadas al sistema bind (vinculación a una dirección y puerto), listen (disposición a recibir) y accept (recepción de una conexión concreta). Ejemplo de un servidor mínimo capaz de recibir un webhook:
from flask import Flask, request
app = Flask(__name__)
@app.post("/webhook")
def webhook():
event = request.get_json(silent=True) or {}
# confirmamos rápido la recepción
return "", 200
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8000)Este proceso escucha en el puerto 8000. Pero con escuchar solo no basta. Hace falta que a ese puerto se pueda llegar desde internet. Y eso ya es una cuestión de dirección pública y alcanzabilidad de red, que un proxy cliente no resuelve por ti.
La diferencia clave en una frase
Un proxy te da una salida a internet bajo la dirección que necesitas. Un webhook necesita una entrada desde internet hacia tu dirección. Salida y entrada no son sinónimos, sino operaciones espejadas. El proxy cliente se ocupa de la salida.
Redes móviles y dirección compartida: por qué una dirección de abonado no se puede direccionar desde afuera
Un tema aparte y muy importante, sobre todo si trabajas con proxies móviles. Aquí la confusión se agrava por la naturaleza de las redes celulares.
Una dirección para muchos: cómo se estructura la salida compartida
En las redes móviles, los abonados por regla general no reciben su propia dirección IP pública. El operador usa tecnología de traducción de direcciones, en la que muchos abonados comparten un pool pequeño de direcciones públicas. Tu smartphone o módem recibe una dirección interna de un rango privado, y hacia afuera todos salen por la pasarela común del operador. Desde afuera, internet ve la dirección del operador, no la tuya personal.
Qué significa esto en la práctica:
- Tu dirección de abonado es una dirección interna dentro de la red del operador. No es enrutable desde internet global.
- Aunque quisieras, no puedes simplemente "abrir un puerto" en una conexión móvil para que un servicio externo llegue hasta tu dispositivo.
- La dirección pública que ven los sitios pertenece a la infraestructura del operador y se comparte entre muchos abonados a la vez.
Por qué esto es fundamentalmente incompatible con la recepción de webhooks
Imagina un enorme centro de oficinas con una única recepción. Todas las llamadas hacia afuera pasan por un número urbano común. Puedes llamar a quien quieras (la llamada saliente funciona). Pero si alguien de afuera marca ese número común, llegará a la recepción, no a ti personalmente en tu escritorio del séptimo piso. La recepción no sabe a quién está destinada exactamente la llamada, porque quien llama no indicó la extensión interna, que en este esquema no existe.
Exactamente así funciona la salida móvil. Una conexión saliente recuerda quién la inició, por eso la respuesta te vuelve a ti. Pero una nueva conexión entrante desde afuera no contiene información sobre a cuál de los miles de abonados corresponde. Por eso un webhook enviado a la dirección común del operador no puede entregarse físicamente a tu dispositivo. No es una limitación de un plan concreto, es una propiedad de la arquitectura.
Proxy móvil y webhooks: dónde está el beneficio real
El proxy móvil de Proxeon resuelve de manera sobresaliente la tarea de las solicitudes salientes bajo una dirección móvil. Esto es muy demandado en escenarios legales: verificar cómo se ve un servicio para usuarios móviles de distintas regiones, recolectar información pública, testear lógica basada en geografía, trabajar con APIs que distinguen tipos de red. Pero recibir webhooks es cosa de entrada, y una entrada a través de una dirección móvil compartida es imposible. Entonces, para la recepción se necesita un componente aparte. De eso hablamos más adelante.
Qué resuelve realmente la tarea de recibir webhooks
Ya entendimos por qué un proxy no es un receptor. Ahora vamos a lo constructivo. Hay cuatro enfoques funcionales, y casi siempre eliges uno de ellos o una combinación.
Enfoque 1: servidor con dirección pública
La forma más directa y predecible. Levantas tu servicio en una máquina con dirección pública permanente y nombre de dominio, configuras TLS y escuchas solicitudes HTTPS entrantes. El servicio externo envía el webhook a tu dominio, tú lo recibes y respondes.
Cuándo elegirlo:
- Tienes o puedes tener un servidor dedicado o una máquina virtual en la nube.
- Quieres la mínima cantidad de eslabones intermedios y el máximo control.
- Necesitas estabilidad, latencia predecible y tus propias reglas de seguridad.
Un manejador de webhooks mínimo pero bien hecho, con verificación de firma, se ve así:
import hmac, hashlib
from flask import Flask, request, abort
app = Flask(__name__)
SECRET = b"your_shared_secret"
def valid_signature(body, signature):
digest = hmac.new(SECRET, body, hashlib.sha256).hexdigest()
return hmac.compare_digest(digest, signature or "")
@app.post("/webhook")
def webhook():
body = request.get_data()
sig = request.headers.get("X-Signature")
if not valid_signature(body, sig):
abort(401)
# aceptar rápido y encolar para procesamiento
enqueue(body)
return "", 200
def enqueue(body):
# poner en un broker o BD, hacer la lógica pesada de forma asíncrona
pass
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8000)Fíjate en dos principios de un procesamiento maduro. Primero: verifica la firma para aceptar solo webhooks auténticos. Segundo: responde rápido con estado 200 y traslada el trabajo pesado a una cola asíncrona; de lo contrario, el emisor empezará a considerarte no disponible por timeout y se pondrá a reintentar la entrega.
Enfoque 2: túnel inverso
Si no tienes tu propio servidor con dirección pública y el servicio corre en una máquina local o detrás de una dirección compartida, ayuda un túnel inverso. La idea es elegante y encaja perfecto en el modelo de direcciones que venimos discutiendo.
Tu máquina misma inicia una conexión saliente hacia un punto público de túnel. Esa conexión permanece abierta. Cuando desde afuera llega un webhook a la dirección pública del túnel, se empuja por el canal ya establecido hacia ti. Mira la belleza: desde afuera nadie inicia comunicación con tu máquina privada. El iniciador fuiste tú cuando levantaste el túnel. Y el webhook viaja por el camino inverso dentro de un canal ya abierto.
Cuándo elegirlo:
- Desarrollo y depuración de integraciones en local.
- No hay posibilidad o ganas de mantener un servidor público.
- Se necesita un punto de recepción temporal o flexible.
Aquí es importante entender el límite de aplicabilidad: la configuración del software de túnel, el enrutamiento y el reenvío de puertos en el router no los detallamos a propósito, es un tema de ingeniería aparte. La idea clave es que el túnel resuelve la entrada gracias a una conexión saliente abierta de antemano.
Enfoque 3: cola del lado del proveedor
Muchas plataformas serias ofrecen no solo webhooks, sino también una cola de mensajes o un bus de eventos de su lado. En lugar de que ellos toquen a tu puerta, tú mismo retiras los eventos de su cola con tu conexión saliente. Esto encaja perfectamente con el modelo del proxy, porque de nuevo todo es saliente.
Cómo funciona conceptualmente:
- El proveedor acumula eventos en su cola o tema.
- Tu consumidor se conecta a la cola y lee los mensajes.
- Tras procesarlos, confirmas la recepción y el mensaje se elimina de la cola.
Una ventaja enorme: si tu consumidor se cae por un rato, los eventos no se pierden, esperan en la cola. Esto elimina el principal dolor de cabeza de los webhooks: la pérdida cuando el receptor no está disponible. Y, lo importante para nuestro tema, todas las llamadas a la cola van hacia afuera, así que pueden pasar por un proxy de Proxeon sin ninguna complicación de dirección pública.
Enfoque 4: sondeo en lugar de suscripción
Si el servicio de terceros no tiene ni cola ni un túnel cómodo, y no puedes recibir el webhook, queda el clásico: el sondeo (polling). Tú mismo preguntas periódicamente a la API si hay eventos nuevos. También son solicitudes salientes, y funcionan perfectamente a través de un proxy.
Al sondeo muchas veces se lo subestima, considerándolo primitivo. En realidad, un sondeo bien diseñado es confiable, simple de operar y no requiere ninguna infraestructura pública. Su único enemigo serio son los límites de solicitudes. Sobre cómo no violarlos trata la siguiente sección extensa.
Cómo elegir el enfoque: un marco breve
- ¿Tienes un servidor público y necesitas la mínima latencia? Ve por el servidor directo con dirección pública.
- ¿No tienes servidor, pero necesitas recibir aquí y ahora, sobre todo para desarrollo? Túnel inverso.
- ¿El proveedor ofrece cola o bus de eventos? Prefiérelo siempre, es la variante más robusta.
- ¿Nada de lo anterior, pero hay una API de lectura? Sondeo a través de proxy.
Sondeo como reemplazo del webhook: cómo diseñarlo para no chocar con los límites
El sondeo es tu aeródromo de respaldo confiable cuando la recepción de entrantes es imposible. Pero una implementación ingenua choca rápido con las restricciones de cantidad de solicitudes y empieza a recibir rechazos. Diseñémoslo bien.
Versión ingenua básica y por qué es mala
Los principiantes escriben algo así:
import time, requests
proxies = {"https": "http://user:pass@gateway.proxeon.net:8080"}
while True:
r = requests.get("https://api.example.com/v1/events", proxies=proxies, timeout=15)
handle(r.json())
time.sleep(1)
def handle(data):
passQué está mal aquí. Una pausa fija de un segundo significa 86400 solicitudes por día, haya eventos o no. Quemas el límite en vano. Si hay un error, el bucle seguirá golpeando el servidor con la misma frecuencia. No hay consideración de los encabezados de límites. Es el camino directo al bloqueo por frecuencia.
Principio 1: sondeo incremental con cursor
No traigas todo de golpe. Pide solo lo que apareció después del último evento conocido. La mayoría de las APIs devuelven un cursor o una marca de tiempo del último evento. Guárdala y pásala en la siguiente solicitud.
state = load_cursor() # por ejemplo, id del último evento
params = {"since": state} if state else {}
r = requests.get("https://api.example.com/v1/events", params=params,
proxies=proxies, timeout=15)
events = r.json().get("items", [])
for e in events:
process(e)
state = e["id"]
save_cursor(state)Así obtienes solo lo nuevo, el volumen de tráfico es mínimo y los duplicados casi se eliminan.
Principio 2: intervalo adaptativo
Sondea seguido cuando los eventos fluyen y con poca frecuencia cuando hay silencio. Una heurística simple: si la respuesta trajo eventos, acorta la pausa; si vino vacía, auméntala hasta un máximo razonable.
min_delay, max_delay = 2, 60
delay = min_delay
while True:
events = poll_once()
if events:
delay = min_delay
else:
delay = min(delay * 2, max_delay)
time.sleep(delay)Esta relajación exponencial reduce drásticamente la cantidad de solicitudes en vano en los períodos tranquilos. Te sorprenderá cuánto baja la carga manteniendo la capacidad de respuesta.
Principio 3: respeta los encabezados de límites
Las buenas APIs devuelven encabezados sobre el estado del límite: cuántas solicitudes quedan y cuándo se reinicia el contador. Léelos y modera el ritmo de antemano, no después del rechazo.
r = requests.get(url, proxies=proxies, timeout=15)
remaining = int(r.headers.get("X-RateLimit-Remaining", "1"))
reset = int(r.headers.get("X-RateLimit-Reset", "0"))
if remaining <= 1 and reset:
wait = max(reset - int(time.time()), 1)
time.sleep(wait)Principio 4: manejo correcto del código 429 y reintentos
Si el servidor igual respondió con código 429 (demasiadas solicitudes), no lo ignores. Mira el encabezado Retry-After y espera el tiempo indicado. Para los errores de red, aplica reintento con demora exponencial y jitter, para no crear picos sincronizados.
import random
def get_with_backoff(url, attempts=5):
delay = 1
for i in range(attempts):
r = requests.get(url, proxies=proxies, timeout=15)
if r.status_code == 429:
retry_after = int(r.headers.get("Retry-After", delay))
time.sleep(retry_after)
continue
if r.status_code >= 500:
time.sleep(delay + random.uniform(0, delay))
delay = min(delay * 2, 30)
continue
return r
raise RuntimeError("too many failures")Principio 5: idempotencia del procesamiento
Con el sondeo son posibles las repeticiones de un mismo evento, sobre todo en los bordes del cursor. Haz el procesamiento idempotente: antes de actuar, verifica si ya procesaste ese evento por su identificador. Esto te salva de cargos duplicados, notificaciones repetidas y otras desagradables sorpresas.
def process(event):
if already_seen(event["id"]):
return
do_business_logic(event)
mark_seen(event["id"])Lista de verificación para un sondeo confiable
- Usa un cursor o marca de tiempo, trae solo lo nuevo.
- Aplica intervalo adaptativo con relajación exponencial.
- Lee y respeta los encabezados de límites.
- Maneja correctamente el 429 y Retry-After.
- Haz reintentos con jitter ante fallos de red.
- Asegura la idempotencia del procesamiento de eventos.
- Registra el cursor y las métricas para ver el retraso.
- Haz pasar las solicitudes salientes por un proxy de Proxeon para la geografía y el tipo de red requeridos, si eso exige la integración.
Dónde el proxy sí es necesario junto a los webhooks
Puede parecer que si el proxy no es un receptor de webhooks, entonces en esta tarea no pinta nada. No es así. El proxy cumple un papel notable, solo que en el otro lado del proceso.
Respuestas salientes y llamadas inversas
El procesamiento de un webhook raras veces termina con un simple 200. A menudo, en respuesta al evento, debes ir a una API de terceros: confirmar la recepción, solicitar detalles del objeto, actualizar el estado en otra plataforma. Todas estas llamadas son salientes, y aquí el proxy de Proxeon es adecuado y útil.
def on_payment_event(event):
order_id = event["order_id"]
# solicitud saliente por los detalles a través del proxy
r = requests.get(f"https://api.partner.com/orders/{order_id}",
proxies=proxies, timeout=15)
details = r.json()
update_internal_state(order_id, details)Para qué exactamente el proxy en estas llamadas
- Geografía de salida estable. Algunas APIs devuelven contenido o precios según la región de la solicitud. El proxy permite llamar desde la ubicación necesaria, de forma legal y predecible.
- Tipo de red requerido. Ciertos servicios responden de manera distinta a solicitudes desde direcciones móviles o fijas. El proxy móvil proporciona el perfil de red correcto para tu tarea.
- Separación de flujos. Al sacar las llamadas salientes a una pasarela gestionada, simplificas el monitoreo, el diagnóstico y el control de la carga.
Sondeo de colas y APIs a través del proxy
Como ya señalamos, los enfoques con cola y sondeo se construyen enteramente sobre conexiones salientes. Entonces, todo ese tráfico pasa naturalmente por el proxy. Resulta una arquitectura ordenada: la recepción de eventos se resuelve con servidor, túnel, cola o sondeo, y toda la comunicación saliente con sistemas externos va por una pasarela proxy gestionada. Cada herramienta hace lo que sabe hacer.
Mini arquitectura de una integración madura
- Punto de recepción de eventos: servidor público, túnel, cola o sondeo.
- Recepción rápida y puesta en cola interna, respuesta 200 sin demora.
- Los workers asíncronos sacan de la cola y ejecutan la lógica de negocio.
- Todas las llamadas salientes a APIs de terceros pasan por el proxy de Proxeon con la geografía y el tipo de red adecuados.
- Idempotencia, reintentos con jitter, métricas y alertas por retraso.
Errores típicos y cómo evitarlos
Reunamos los tropiezos más frecuentes. Revisa esta lista contigo mismo.
Error 1: esperar un webhook en la dirección del proxy
El más común. La persona pone la dirección del proxy en la configuración del webhook del servicio de terceros y espera la entrega. Nunca llega, porque es una dirección de salida, no un punto de recepción. Solución: usa uno de los cuatro enfoques funcionales de recepción y no confundas la salida con la entrada.
Error 2: intentar hacer que una dirección móvil sea públicamente direccionable
Los intentos de llegar desde afuera hasta un abonado móvil concreto están condenados por la salida compartida del operador. No pierdas tiempo en eso. Para la recepción usa un servidor público, un túnel, o abandona el webhook en favor del sondeo y la cola.
Error 3: trabajo pesado dentro del manejador del webhook
Si ejecutas lógica larga de forma síncrona antes de responder 200, el emisor considerará que no estás disponible por timeout y empezará a mandar reintentos. Recibirás una tormenta de duplicados. Solución: acepta al instante y encola, haz lo pesado de forma asíncrona.
Error 4: falta de verificación de firma
Un endpoint abierto sin verificación de autenticidad acepta cualquier cosa de cualquiera. Es un riesgo. Verifica siempre la firma del webhook entrante con el secreto compartido y rechaza las solicitudes sin firma.
Error 5: sondeo ingenuo sin considerar los límites
Una pausa fija de un segundo y el ignorar los encabezados de límites llevan a rechazos por frecuencia. Aplica intervalo adaptativo, cursor y respeto por Retry-After.
Error 6: falta de idempotencia
Tanto los webhooks como el sondeo pueden entregar un mismo evento dos veces. Sin protección por identificador, te arriesgas a acciones duplicadas. Verifica siempre si ya procesaste el evento antes.
Error 7: mezclar entrante y saliente en un mismo nodo sin separación
Cuando la recepción de eventos y las llamadas salientes están amontonadas, el diagnóstico se vuelve una pesadilla. Separa los roles: punto de recepción por un lado, pasarela saliente a través del proxy por otro.
Error 8: fallos silenciosos de recepción
Si el punto de recepción se cayó y no lo notaste, los eventos se pierden en silencio. Configura monitoreo de disponibilidad del endpoint y del retraso de la cola, para enterarte del problema antes que nadie.
Herramientas y recursos
Qué usar en la práctica, ordenado por capas.
Para recibir eventos
- Frameworks web. Marcos livianos para un endpoint rápido de recepción: sirve cualquier solución popular de tu lenguaje. Lo importante es que el manejador responda rápido y sepa encolar tareas.
- Túneles inversos. Herramientas que abren una conexión saliente hacia un punto público y empujan las solicitudes entrantes hacia ti. Útiles para desarrollo y escenarios temporales.
- Colas y buses de eventos de proveedores. Si la plataforma ofrece lectura de eventos desde una cola, suele ser la mejor opción por confiabilidad.
Para procesamiento asíncrono
- Brokers de mensajes. La cola interna entre recepción y procesamiento desacopla la recepción rápida de la lógica lenta.
- Workers y planificadores. Ejecutores en segundo plano que sacan de la cola, hacen reintentos y respetan la idempotencia.
Para llamadas salientes
- Clientes HTTP con soporte de proxy. Prácticamente cualquier biblioteca madura sabe trabajar a través de un proxy; configura la dirección de la pasarela, los timeouts y los reintentos.
- Pasarela proxy de Proxeon. Punto de salida gestionado para solicitudes salientes con la geografía y el tipo de red necesarios, incluidas direcciones móviles, para tareas de ingeniería legales.
Para observabilidad
- Logs con contexto. Registra el identificador del evento, el cursor del sondeo, los códigos de respuesta y el tiempo de procesamiento.
- Métricas. Retraso de la cola, proporción de 429, cantidad de reintentos, latencia de recepción. Son tus indicadores tempranos de problemas.
- Alertas. Aviso de indisponibilidad del endpoint y de crecimiento del retraso.
Casos y resultados
Mostremos cómo funcionan los principios en la práctica. Los ejemplos son compuestos, pero reflejan situaciones típicas y órdenes de magnitud.
Caso 1: integración de notificaciones de estado sin servidor propio
Un equipo pequeño integró una plataforma que envía webhooks sobre cambios de estado. No tenían servidor público propio, y los primeros intentos de poner la dirección del proxy en la configuración del webhook no dieron nada, como era de esperar: no hubo entregas. Tras desglosar el modelo de direcciones, el equipo pasó a dos soluciones a la vez.
Para la etapa de desarrollo usaron un túnel inverso, para depurar el manejador en local. Para producción, la plataforma ofrecía lectura desde una cola, y el equipo trasladó la recepción a ella. Resultado: las pérdidas de eventos durante reinicios breves del servicio cayeron a cero, porque la cola retiene los mensajes. Todas las solicitudes salientes de aclaración a la API de la plataforma pasaron por el proxy de Proxeon con la geografía necesaria. El diagnóstico se simplificó, porque la entrada y la salida quedaron separadas.
Caso 2: paso de webhooks a sondeo cuando la recepción es imposible
El servicio operaba en un entorno donde la recepción de entrantes era imposible por razones arquitectónicas. Al principio intentaron recibir webhooks, pero no había entregas. Decidieron abandonar la suscripción y construir un sondeo. La primera versión con pausa fija de un segundo casi de inmediato chocó con los límites y empezó a recibir rechazos por frecuencia.
Tras la reelaboración, incorporaron sondeo incremental con cursor, intervalo adaptativo de 2 a 60 segundos, respeto por los encabezados de límites y manejo correcto del 429. La cantidad de solicitudes en horas tranquilas se redujo varias veces gracias a la relajación exponencial. Los rechazos por frecuencia desaparecieron. La latencia de obtención de nuevos eventos en períodos activos se mantuvo dentro de unos pocos segundos, lo que dejó plenamente satisfecho al negocio. Todas las solicitudes pasaban por el proxy, lo que aseguraba el perfil de red necesario.
Caso 3: tormenta de duplicados por un manejador lento
La integración con un servidor público funcionaba, pero cada tanto el manejador ejecutaba lógica síncrona pesada y no alcanzaba a responder 200 en el tiempo previsto. El emisor consideraba la entrega fallida y la repetía, generando duplicados y acciones dobles. Los típicos tropiezos.
La solución resultó directa. El manejador pasó a aceptar el evento al instante, verificar la firma, poner la tarea en una cola interna y responder 200 de inmediato. La lógica pesada se trasladó a workers asíncronos. Además, se introdujo idempotencia por el identificador del evento. Los duplicados dejaron de provocar acciones repetidas, y el tiempo de respuesta del endpoint se volvió estable y bajo. La tormenta de reintentos cesó.
Conclusión general de los casos
En todas las historias la raíz del problema era una sola: la confusión entre la dirección saliente y la entrante, y el intento de cargarle al proxy un papel de receptor que no le corresponde. En cuanto los equipos separaban los roles y elegían la herramienta según la dirección, todo se acomodaba. El proxy se encargaba de la salida, y la entrada se resolvía con servidor, túnel, cola o sondeo.
Tabla: tarea y solución adecuada
Ten a mano esta brújula compacta. Ahorra horas de discusión.
Correspondencia entre tareas y herramientas
- Solicitud saliente a una API de terceros con la geografía necesaria. Solución: proxy de Proxeon. Dirección: saliente. No se necesita dirección pública.
- Solicitud saliente bajo un tipo de red móvil. Solución: proxy móvil de Proxeon. Dirección: saliente. No se necesita dirección pública.
- Recepción de un webhook con servidor público disponible. Solución: servidor con dirección pública y TLS. Dirección: entrante. La dirección pública es obligatoria.
- Recepción de un webhook sin servidor propio, para desarrollo. Solución: túnel inverso. Dirección: entrante dentro de un canal saliente abierto de antemano.
- Recepción de eventos con garantía de conservación durante inactividad. Solución: cola o bus de eventos del proveedor, lectura por tu propio consumidor. Dirección: lectura saliente.
- Recepción de eventos con imposibilidad total de entrantes. Solución: sondeo a través de proxy con cursor e intervalo adaptativo. Dirección: saliente.
- Llamadas de aclaración en respuesta a un evento. Solución: solicitudes salientes a través del proxy de Proxeon. Dirección: saliente.
- Llegar desde afuera a un abonado móvil concreto. Solución: imposible por la salida compartida del operador. Usa otros enfoques de recepción.
Regla de elección en una línea
Si el iniciador de la conexión eres tú, tu herramienta es el proxy. Si el iniciador es el mundo exterior, necesitas un servidor, un túnel, una cola o reemplazar la suscripción por sondeo.
FAQ: preguntas frecuentes
¿Se puede configurar un proxy para que le lleguen webhooks?
No. Un proxy cliente atiende tus solicitudes salientes y no es un punto de recepción que escuche públicamente conexiones ajenas dirigidas hacia ti. La dirección del proxy es una dirección de salida, no de entrada. Para recibir webhooks usa un servidor público, un túnel inverso, una cola del proveedor o sondeo.
¿Por qué el webhook no llega a una dirección móvil?
Porque en una red móvil los abonados salen a internet a través de una dirección común del operador, y la dirección propia del dispositivo es interna y no se enruta desde afuera. Una nueva conexión entrante desde afuera no sabe a cuál abonado exactamente está destinada, por eso la entrega a un dispositivo concreto es imposible. Es una propiedad de la arquitectura de red, no una limitación del plan.
Si no tengo servidor público, ¿cómo recibo eventos?
Hay tres caminos. Primero, el túnel inverso, que empuja los entrantes por un canal saliente que tú abriste de antemano, cómodo para desarrollo. Segundo, la lectura desde una cola o bus de eventos, si el proveedor lo ofrece, la variante más confiable. Tercero, el sondeo de la API con tus propias solicitudes salientes. Los dos últimos funcionan perfectamente a través de un proxy.
El sondeo no es ineficiente, ¿o sí?
El sondeo ingenuo es realmente derrochador. Pero un sondeo bien hecho, con cursor incremental, intervalo adaptativo, respeto por los límites e idempotencia, es económico y confiable. En los períodos tranquilos la cantidad de solicitudes cae drásticamente gracias a la relajación exponencial, y en los activos obtienes los eventos en pocos segundos. Para muchas tareas eso es más que suficiente.
¿Hace falta un proxy si recibo webhooks?
Para la recepción en sí, el proxy no hace falta: recibir es la dirección entrante. Pero el proxy es muy útil para las llamadas salientes que haces en respuesta a los eventos: por los detalles del objeto, para confirmar, para actualizar el estado en otras plataformas. Y también para el sondeo y la lectura de colas, porque eso es tráfico saliente.
¿Cómo proteger el endpoint de recepción de webhooks?
Verifica la firma de la solicitud entrante con el secreto compartido y rechaza las que no tengan firma. Usa TLS. Responde rápido y traslada el procesamiento a una cola asíncrona. Haz el procesamiento idempotente, para que una entrega repetida no provoque acciones repetidas. Registra y monitorea la disponibilidad.
¿Qué hacer si los eventos a veces llegan dos veces?
Es una situación normal tanto para webhooks como para sondeo. Asegura la idempotencia: antes de ejecutar la lógica, verifica por el identificador del evento si ya lo procesaste antes, y marca los procesados. Así los duplicados serán inofensivos.
¿Se puede usar un proxy móvil para las solicitudes salientes en una integración con webhooks?
Sí, y es un escenario legal frecuente. El proxy móvil de Proxeon brinda el tipo de red y la geografía necesarios para las llamadas salientes a APIs de terceros y para el sondeo. Al mismo tiempo, la recepción de los webhooks se resuelve con un componente aparte, porque recibir es la entrada, y la salida móvil es compartida y no se puede direccionar desde afuera.
¿Cuál es la diferencia entre la cola del proveedor y el webhook en cuanto a confiabilidad?
El webhook se entrega en el momento del evento, y si tu receptor no está disponible, el evento puede perderse o requerir reintentos por parte del emisor. La cola retiene los eventos hasta que los leas y los confirmes. Por eso, ante breves inactividades del consumidor, los datos no se pierden. Si el proveedor ofrece una cola, por lo general es preferible por su robustez.
¿Describen la configuración del router y el reenvío de puertos?
No, es un tema vecino con su propia especificidad, y a propósito lo dejamos fuera de alcance. Aquí lo importante es entender el modelo de direcciones y elegir la herramienta. Si levantas tu propio punto de recepción detrás de equipos domésticos, las cuestiones de enrutamiento se resuelven por separado y requieren su propio análisis.
Conclusión: juntemos todo
Recorrimos el camino desde una idea equivocada común hasta un modelo de ingeniería ordenado. La conclusión principal es simple y potente: un proxy resuelve la tarea de las solicitudes salientes, pero no hace que tu servicio sea accesible desde afuera. Todo depende de la dirección de la conexión. Cuando el iniciador eres tú, el proxy está en su lugar. Cuando el iniciador es el mundo exterior, hace falta otra herramienta.
Desglosamos por qué un proxy cliente no escucha un puerto ni da una dirección pública, y por qué una dirección de abonado móvil es fundamentalmente no direccionable desde afuera debido a la salida compartida del operador. Vimos cuatro enfoques funcionales para recibir webhooks: servidor con dirección pública, túnel inverso, cola del lado del proveedor y sondeo en lugar de suscripción. Diseñamos un sondeo confiable que no choca con los límites gracias al cursor, el intervalo adaptativo, el respeto por los encabezados y la idempotencia. Y vimos dónde el proxy de Proxeon es realmente útil junto a los webhooks: en las respuestas salientes, las llamadas a APIs de terceros, la lectura de colas y el sondeo.
¿Qué hacer ahora? Determina la dirección de tu tarea. Si es una entrada,
