Impossible de connecter n8n à Google Drive depuis la Chine continentale : à la recherche de solutions pour obtenir les URLs vidéo pour l'automatisation des réseaux sociaux avec Buffer

Questions
,
1

J’essaie d’automatiser la publication sur les réseaux sociaux (Facebook, Instagram, X, YouTube et TikTok) en utilisant n8n et Buffer. Mon plan initial était de lire des fichiers locaux, de les synchroniser avec Google Drive pour obtenir une URL publique, puis de transmettre cette URL à Buffer. Cependant, je ne parviens pas à authentifier n8n avec Google Drive, j’obtiens une erreur de timeout de connexion.

Erreur : connect ETIMEDOUT 74.125.199.95:443

Plus de détails

Échec de la connexion. La fenêtre peut maintenant être fermée.

Je soupçonne que cela est dû à des restrictions réseau de la Chine continentale ??, mais tout mon reste fonctionne très bien.

Comment puis-je résoudre ce problème de connexion, ou existe-t-il d’autres moyens ou solutions de contournement pour atteindre le même objectif d’obtenir une URL vidéo pour Buffer sans dépendre de Google Drive ?

2

@Aria

L’alternative la plus robuste et accessible pour les utilisateurs de votre région est Cloudflare R2. Il s’agit d’un service de stockage d’objets compatible S3 qui est généralement beaucoup plus accessible et offre un moyen simple de générer des URL publiques.

Suivez ce guide :

1. Configurer Cloudflare R2

  1. Connectez-vous à votre tableau de bord Cloudflare → R2 → Create Bucket.
  2. Donnez un nom à votre bucket (par exemple, social-media-assets).
  3. Étape cruciale : Allez dans Settings du bucket → Public Access.
    • Activez soit le R2.dev subdomain (pour les tests), soit connectez un Custom Domain (recommandé pour la production). Cela vous donne l’URL de base (par exemple, https://pub-aaa.r2.dev ou https://cdn.yourdomain.com).

2. Configurer le nœud S3 de n8n

Comme R2 utilise le protocole S3, utilisez le nœud S3 dans n8n :

  • Credentials : Créez des identifiants S3.
    • Access Key ID & Secret Access Key : Obtenez-les depuis la page « Manage R2 API Tokens » dans Cloudflare.
    • Endpoint : Utilisez votre endpoint R2 S3 (par exemple, https://<accountid>.r2.cloudflarestorage.com).
  • Operation : Upload a File.
  • Bucket : social-media-assets.
  • File Content : Passez les données binaires du nœud de lecture de fichier local.

3. Construire l’URL publique

Le nœud S3 télécharge le fichier, mais il ne « retourne » pas automatiquement l’URL publique. Vous pouvez facilement la construire en utilisant un nœud Set ou une expression : https://your-public-endpoint.com/{{ $json.key }} (Où {{ $json.key }} est le nom du fichier/le chemin retourné par le nœud S3).

4. Passer l’URL à Buffer

Maintenant, utilisez le nœud HTTP Request pour appeler l’API Buffer :

  • Method : POST
  • URL : https://api.bufferapp.com/1/updates/create.json
  • Body (JSON) :
{
  "profile_ids": ["YOUR_PROFILE_ID"],
  "text": "Your awesome caption!",
  "media": {
    "photo": "https://your-public-endpoint.com/video.mp4" 
  }
}
3

Salut @Aria, le délai d’expiration vient du Grand Firewall, pas de n8n. 74.125.x.x est une plage Google, et les APIs Google, y compris Drive, sont bloquées depuis la Chine continentale. L’échec de la fenêtre OAuth est attendu. Tes autres nœuds fonctionnent parce qu’ils ne contactent pas Google.

L’approche R2 de kjooleng est solide architecturalement, mais il y a un point à clarifier avant que tu y passes du temps : Cloudflare n’est pas un moyen fiable de contourner le firewall. Les IPs de Cloudflare sont limitées et réinitialisées par le GFW selon la province et l’ISP, et le sous-domaine public r2.dev en particulier a un historique de blocage en Chine continentale. Si tu utilises R2, utilise un domaine personnalisé, pas r2.dev.

Voici la partie qui compte vraiment pour ta configuration. Une seule partie de ceci doit traverser le firewall : ta boîte n8n qui envoie le fichier. Buffer récupère l’URL depuis ses propres serveurs en dehors de la Chine, donc une URL bloquée en Chine n’affecte pas du tout Buffer. Ça inverse la question. Ce n’est pas « l’URL est-elle accessible depuis la Chine », c’est « mon instance n8n peut-elle atteindre le point de terminaison de stockage pour envoyer ».

Donc avant de t’engager :

  • Teste le point de terminaison d’envoi depuis ton hôte n8n. Pour R2, c’est curl -I https://<accountid>.r2.cloudflarestorage.com. S’il se bloque, l’envoi aussi.
  • Si c’est instable, oublie la lutte et utilise un magasin d’objets natif à la Chine : Alibaba Cloud OSS ou Tencent COS. Les deux sont compatibles S3, les deux te donnent une URL publique que Buffer peut récupérer, et aucun des deux ne dépend des conditions du GFW qui restent stables au jour le jour. Pour quelqu’un qui opère en Chine continentale, c’est généralement le chemin le moins maintenance-intensif.

Même schéma de chaque côté : envoie le fichier, construis l’URL publique, passe-la à Buffer. La seule vraie décision est quel point de terminaison de stockage ta boîte n8n peut contacte de manière fiable.

Mike

4

Alibaba OSS ou Tencent COS est la bonne direction puisque tu es derrière le Grand Firewall, mais teste l’URL réelle aussi de l’extérieur de la Chine avant de l’intégrer. Certains CDN régionaux ont l’air publics localement et ensuite les serveurs du scheduler ne peuvent pas les atteindre, ce qui retourne simplement le problème de connectivité.

Quel que soit le stockage que tu choisisses, l’URL doit rester publique et non expirante quand le scheduler la récupère, pas seulement quand tu la testes 10 minutes plus tôt. Les URL signées qui expirent avant la publication sont une défaillance très courante qui ressemble à un bug de plateforme.

J’ai rencontré le même type de problème en exécutant blotato depuis n8n. La cause première était une URL de prévisualisation/temporaire au lieu d’un vrai fichier public. Un diagnostic utile : les erreurs de media-fetch affichent parfois le premier caractère de la réponse, donc un « e » peut indiquer une URL expirée. Et si Google Drive revient plus tard, utilise le format drive.usercontent.google.com/download avec l’ID du fichier. Le lien /view normal ne fonctionnera pas pour cela.

5

Merci de nous en avoir informés, nous avons créé CV-10 comme ticket de développement interne pour l’examiner.

6

Nous avons examiné cette question et nous ne pouvons pas confirmer qu’il s’agit d’un bug. Pour l’instant, nous avons fermé le ticket interne, mais si cela commence à ressembler à un bug, notre équipe de modération le signalera à nouveau.

7

L’approche Cloudflare R2 de kjooleng est la bonne voie ici. Quelques points à noter si vous exécutez n8n auto-hébergé en Chine :

  • Héberger n8n en dehors de la Chine : Si votre instance n8n se trouve derrière le pare-feu, tous les appels sortants vers les API Google (pas seulement Drive) rencontreront le même ETIMEDOUT. Envisagez de déployer n8n sur un serveur en dehors de la Chine continentale (par exemple, région HK, Singapour) et programmez les workflows à partir de là.

  • Alternative pour les URL vidéo : Si vous n’avez besoin que d’une URL publique pour les vidéos à transmettre à Buffer, vous pouvez également utiliser Alibaba Cloud OSS (aliyuncs) ou Tencent COS — tous deux sont fiables en Chine et supportent les URL présignées/publiques. Le nœud compatible S3 de n8n fonctionne avec les deux.

  • Remarque sur l’API Buffer : Buffer accepte les URL vidéo directes, donc n’importe quelle URL CDN publique (R2, OSS, COS) fonctionnera tant qu’elle est publiquement accessible.

8

Salut ! Ton intuition est absolument correcte.

L’adresse IP 74.125.199.95 appartient à Google. L’erreur connect ETIMEDOUT signifie que ton instance n8n tente d’établir une liaison TCP avec les serveurs API de Google, mais la connexion est entièrement interrompue par le pare-feu réseau (très courant avec les restrictions de la Chine continentale).

Comme ton objectif est simplement d’obtenir une URL publique à transmettre à Buffer, tu as deux solutions :

Option 1 : Acheminer le trafic n8n via un proxy (si tu dois absolument utiliser Google Drive)
Si tu dispose d’un serveur proxy situé en dehors de la région restreinte, tu peux forcer n8n à router son trafic à travers celui-ci. Tu dois ajouter ces variables d’environnement à ton 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 # Essentiel pour que les webhooks n8n locaux ne passent pas par le proxy

Option 2 : Stockage cloud alternatif (fortement recommandé pour Buffer) Si configurer un proxy est trop compliqué, la meilleure solution est de contourner Google entièrement et d’utiliser un service qui n’est pas bloqué et qui gère mieux les médias.

  • Cloudinary : C’est franchement la meilleure option pour la publication sur les réseaux sociaux. Elle dispose d’un nœud dédié n8n, n’est généralement pas ciblée par les blocages généraux, et génère automatiquement des URL publiques optimisées pour les images/vidéos. (Workflow : Lire fichier local -
    Télécharger vers Cloudinary -
    Transmettre l’URL Cloudinary à Buffer)

  • AWS S3 / DigitalOcean Spaces / Bunny.net : Stockage d’objets standard. Tu peux télécharger le fichier binaire là-bas (en hébergeant le bucket en dehors de la zone restreinte) et construire une URL de lecture publique à envoyer à Buffer.

Passer à Cloudinary ou S3 sera probablement beaucoup plus stable pour ton pipeline automatisé de publication sur les réseaux sociaux que de te battre avec le pare-feu pour l’accès à Google Drive. J’espère que cela t’aidera !