Estoy intentando automatizar la publicación en redes sociales en Facebook, Instagram, X, YouTube y TikTok usando n8n y Buffer. Mi plan original era leer archivos locales, sincronizarlos a Google Drive para obtener una URL pública y luego pasar esa URL a Buffer. Sin embargo, no puedo autenticar n8n con Google Drive y recibo un error de tiempo de conexión agotado.
Error: connect ETIMEDOUT 74.125.199.95:443
Más detalles
No se pudo conectar. La ventana se puede cerrar ahora.
Sospecho que esto se debe a restricciones de red desde China continental?? pero todo lo demás funciona muy bien.
¿Cómo puedo resolver este problema de conexión, o hay formas alternativas u otros recursos para lograr el mismo objetivo de obtener una URL de video para Buffer sin depender de Google Drive?
La alternativa más robusta y accesible para usuarios en tu región es Cloudflare R2. Es un servicio de almacenamiento de objetos compatible con S3 que es generalmente mucho más accesible y proporciona una forma directa de generar URLs públicas.
Sigue esta guía:
1. Configurar Cloudflare R2
Inicia sesión en tu panel de Cloudflare → R2 → Create Bucket.
Asigna un nombre a tu bucket (por ejemplo, social-media-assets).
Paso Crucial: Ve a la Settings del bucket → Public Access.
Habilita el R2.dev subdomain (para pruebas) o conecta un Custom Domain (recomendado para producción). Esto te proporciona la URL base (por ejemplo, https://pub-aaa.r2.dev o https://cdn.yourdomain.com).
2. Configurar el nodo S3 de n8n
Como R2 utiliza el protocolo S3, usa el nodo S3 en n8n:
Credentials: Crea una credencial S3.
Access Key ID y Secret Access Key: Obtén estos de la página “Manage R2 API Tokens” de R2 en Cloudflare.
Endpoint: Usa tu endpoint S3 de R2 (por ejemplo, https://<accountid>.r2.cloudflarestorage.com).
Operation:Upload a File.
Bucket:social-media-assets.
File Content: Pasa los datos binarios del nodo de lectura de archivo local.
3. Construir la URL Pública
El nodo S3 carga el archivo, pero no devuelve la URL pública automáticamente. Puedes construirla fácilmente usando un nodo Set o una expresión: https://your-public-endpoint.com/{{ $json.key }}(Donde {{ $json.key }} es el nombre/ruta del archivo devuelta por el nodo S3).
4. Pasar la URL a Buffer
Ahora, usa el nodo HTTP Request para llamar a la API de Buffer:
Hey @Aria el timeout es la Gran Muralla de Fuego (Great Firewall), no n8n. 74.125.x.x es un rango de Google, y las APIs de Google incluyendo Drive están bloqueadas desde la China continental. El fallo de la ventana OAuth es esperado. Tus otros nodos funcionan porque no están accediendo a Google.
El enfoque R2 de kjooleng es arquitectónicamente válido, pero hay algo importante que aclarar antes de que inviertas tiempo en ello: Cloudflare no es una forma confiable de eludir el firewall. Las IPs de Cloudflare se ralentizan y se reinician por la GFW dependiendo de la provincia e ISP, y el subdominio público r2.dev específicamente tiene un historial de estar bloqueado en la China continental. Si usas R2, usa un dominio personalizado, no r2.dev.
Pero aquí está la parte que realmente importa para tu configuración. Solo una parte de esto tiene que cruzar el firewall: tu caja n8n subiendo el archivo. Buffer obtiene la URL de sus propios servidores fuera de China, así que una URL bloqueada dentro de China no afecta a Buffer en absoluto. Eso voltea la pregunta. No es “¿la URL es accesible desde China?”, es “¿puede mi instancia n8n alcanzar el endpoint de almacenamiento para subir?”
Así que antes de comprometerte:
Prueba el endpoint de carga desde tu host n8n. Para R2 es curl -I https://<accountid>.r2.cloudflarestorage.com. Si se congela, la carga también se congelará.
Si es inestable, sáltate la pelea y usa un almacén de objetos nativo de China: Alibaba Cloud OSS o Tencent COS. Ambos son compatibles con S3, ambos te dan una URL pública que Buffer puede obtener, y ninguno depende de que las condiciones de GFW se mantengan estables día a día. Para alguien que opera dentro del continente, ese suele ser el camino de menor mantenimiento.
El mismo patrón de cualquier forma: sube el archivo, construye la URL pública, pásala a Buffer. La única decisión real es cuál endpoint de almacenamiento puede tu caja n8n comunicarse de forma confiable.
Alibaba OSS o Tencent COS es la dirección correcta si estás dentro de la Gran Muralla, pero prueba la URL real desde fuera de China también antes de implementarla. algunos CDN regionales se ven públicos localmente y luego los servidores del programador no pueden alcanzarlos, lo que simplemente invierte el problema de conectividad.
cualquiera que sea el almacenamiento que elijas, la URL tiene que permanecer pública y sin expiración cuando el programador la obtiene, no solo cuando la pruebas 10 minutos antes. las URLs firmadas que expiran antes de la publicación es un fallo muy común que se parece a un error de plataforma.
tuve el mismo tipo de problema ejecutando blotato desde n8n. la causa raíz fue una URL de vista previa/temporal en lugar de un archivo público real. un diagnóstico útil: los errores de obtención de medios a veces muestran el primer carácter de la respuesta, por lo que una e puede apuntar a una URL expirada. y si Google Drive vuelve más tarde, usa el formato drive.usercontent.google.com/download con el ID del archivo. el enlace /view normal no funcionará para esto.
Hemos examinado este problema y no podemos confirmar que se trate de un error. Por ahora hemos cerrado el ticket interno, pero si empieza a parecer que es un error, nuestro equipo de moderación lo marcará nuevamente.
El enfoque de Cloudflare R2 de kjooleng es el camino correcto aquí. Algunos puntos a tener en cuenta si ejecutas n8n alojado por ti mismo dentro de China:
Aloja n8n fuera de China: Si tu instancia de n8n está dentro del cortafuegos, todas las llamadas salientes a las APIs de Google (no solo Drive) encontrarán el mismo ETIMEDOUT. Considera implementar n8n en un servidor fuera de la China continental (por ejemplo, región de Hong Kong o Singapur) y programa los flujos de trabajo desde allí.
Alternativa para URLs de video: Si solo necesitas una URL pública para videos para pasar a Buffer, también puedes usar Alibaba Cloud OSS (aliyuncs) o Tencent COS — ambos son confiables dentro de China y admiten URLs presignadas/públicas. El nodo compatible con S3 de n8n funciona con ambos.
Nota sobre la API de Buffer: Buffer acepta URLs de video directas, por lo que cualquier URL de CDN pública (R2, OSS, COS) funcionará siempre que sea accesible públicamente.
La IP 74.125.199.95 pertenece a Google. El error connect ETIMEDOUT significa que tu instancia de n8n está intentando iniciar un apretón de manos TCP con los servidores de API de Google, pero la conexión está siendo descartada completamente por el firewall de red (muy común con restricciones de China continental).
Ya que tu objetivo es simplemente obtener una URL pública para pasar a Buffer, tienes dos formas de resolver esto:
Opción 1: Tunelizar tráfico de n8n a través de un Proxy (Si debes usar Google Drive)
Si tienes un servidor proxy ubicado fuera de la región restringida, puedes forzar que n8n dirija su tráfico a través de él. Necesitas agregar estas variables de entorno a tu docker-compose.yml de n8n:
environment:
- HTTP_PROXY=[http://your.proxy.server.ip](http://your.proxy.server.ip):port
- HTTPS_PROXY=[http://your.proxy.server.ip](http://your.proxy.server.ip):port
- NO_PROXY=localhost,127.0.0.1 # Crucial para que los webhooks locales de n8n no se dirijan a través del proxy
Opción 2: Almacenamiento en la Nube Alternativo (Altamente Recomendado para Buffer) Si configurar un proxy es demasiado complicado, la mejor solución es omitir Google completamente y usar un servicio que no esté bloqueado y que maneje mejor los medios.
Cloudinary: Honestamente, esta es la mejor opción para publicaciones en redes sociales. Tiene un nodo dedicado en n8n, típicamente no es objetivo de bloqueos generales, y genera automáticamente URLs públicas optimizadas para imágenes/videos. (Flujo de trabajo: Leer Archivo Local -\ Carga a Cloudinary -\ Pasar URL de Cloudinary a Buffer)
AWS S3 / DigitalOcean Spaces / Bunny.net: Almacenamiento de objetos estándar. Puedes cargar el archivo binario allí (alojando el depósito fuera de la zona restringida) y construir una URL de lectura pública para enviar a Buffer.
Cambiar a Cloudinary o S3 probablemente será mucho más estable para tu pipeline de redes sociales automatizado que luchar contra el firewall para acceder a Google Drive. ¡Espero que esto te ayude!