Kann n8n von Festlandchina aus nicht mit Google Drive verbinden: Suche nach Lösungen für Video-URLs zur Buffer-Social-Media-Automatisierung

Ich versuche, Social-Media-Posts zu Facebook, Instagram, X, YouTube und TikTok mit n8n und Buffer zu automatisieren. Mein ursprünglicher Plan war, lokale Dateien zu lesen, sie mit Google Drive zu synchronisieren, um eine öffentliche URL zu erhalten, und diese URL dann an Buffer weiterzugeben. Allerdings kann ich n8n nicht mit Google Drive authentifizieren und erhalte einen Connection-Timeout-Fehler.

Error: connect ETIMEDOUT 74.125.199.95:443

Weitere Details

Verbindung fehlgeschlagen. Das Fenster kann jetzt geschlossen werden.

Ich vermute, dass dies an Netzwerkbeschränkungen vom chinesischen Festland liegt?? aber all meine anderen Systeme funktionieren sehr gut.

Wie kann ich dieses Verbindungsproblem lösen, oder gibt es alternative Möglichkeiten oder Workarounds, um das gleiche Ziel zu erreichen – eine Video-URL für Buffer zu bekommen – ohne mich auf Google Drive zu verlassen?

@Aria

Die robusteste und zugänglichste Alternative für Benutzer in deiner Region ist Cloudflare R2. Es ist ein S3-kompatibler Objektspeicherdienst, der generell viel leichter zugänglich ist und eine unkomplizierte Möglichkeit bietet, öffentliche URLs zu generieren.

Folge dieser Anleitung:

1. Cloudflare R2 einrichten

  1. Melde dich in deinem Cloudflare-Dashboard an → R2Bucket erstellen.
  2. Gib deinem Bucket einen Namen (z. B. social-media-assets).
  3. Wichtiger Schritt: Gehe zu den Bucket-EinstellungenÖffentlicher Zugriff.
    • Aktiviere entweder die R2.dev-Subdomain (zum Testen) oder verbinde eine Custom Domain (empfohlen für Produktion). Dies gibt dir die Basis-URL (z. B. https://pub-aaa.r2.dev oder https://cdn.yourdomain.com).

2. Konfiguriere den n8n S3-Node

Da R2 das S3-Protokoll verwendet, nutze den S3-Node in n8n:

  • Anmeldedaten: Erstelle eine S3-Anmeldedaten.
    • Access Key ID & Secret Access Key: Hole diese von der R2-Seite „R2 API-Token verwalten

Hey @Aria das Timeout ist die Great Firewall, nicht n8n. 74.125.x.x ist ein Google-Range, und Google-APIs einschließlich Drive sind von Festlandchina blockiert. Das fehlgeschlagene OAuth-Fenster ist zu erwarten. Deine anderen Nodes funktionieren, weil sie nicht auf Google zugreifen.

kjooleng’s R2-Ansatz ist architektonisch sinnvoll, aber eine Sache, die geklärt werden sollte, bevor du Zeit investierst: Cloudflare ist keine zuverlässige Möglichkeit, um die Firewall zu umgehen. Cloudflare-IPs werden von der GFW je nach Provinz und ISP gedrosselt und zurückgesetzt, und die öffentliche r2.dev-Subdomain hat speziell eine Geschichte von Blockierungen in Festlandchina. Wenn du R2 verwendest, nutze eine benutzerdefinierte Domain, nicht r2.dev.

Hier ist der Teil, der eigentlich für dein Setup zählt. Nur ein Teil davon muss die Firewall überqueren: dein n8n-Box beim Hochladen der Datei. Buffer zieht die URL von seinen eigenen Servern außerhalb Chinas, also hat eine blockierte URL in China keine Auswirkungen auf Buffer. Das dreht die Frage um. Es geht nicht um „ist die URL von China aus erreichbar,

Alibaba OSS oder Tencent COS ist die richtige Richtung, wenn du hinter der Great Firewall bist, aber teste die tatsächliche URL auch von außerhalb Chinas, bevor du sie einbindest. Einige regionale CDNs sehen lokal öffentlich aus, aber dann können die Server des Schedulers sie nicht erreichen, was das Konnektivitätsproblem einfach umdreht.

Welcher Speicher auch immer gewählt wird, die URL muss öffentlich und nicht ablaufend bleiben, wenn der Scheduler sie abruft, nicht nur wenn du sie 10 Minuten früher testest. Signierte URLs, die vor der Veröffentlichung ablaufen, sind eine sehr häufige Fehlerquelle, die wie ein Plattformfehler aussieht.

Ich bin auf das gleiche Problem gestoßen, als ich blotato über n8n ausgeführt habe. Die Grundursache war eine Vorschau-/Temp-URL statt einer echten öffentlichen Datei. Ein nützliches Diagnosetool: Media-Fetch-Fehler zeigen manchmal das erste Zeichen der Antwort, also ein „e

Danke, dass du uns darauf hinweist! Wir haben CV-10 als internes Entwickler-Ticket erstellt, um uns damit zu befassen.

Wir haben uns diese Angelegenheit angesehen und können nicht bestätigen, dass es sich um einen Fehler handelt. Wir haben das interne Ticket vorerst geschlossen, aber falls es anfängt, wie ein Fehler auszusehen, wird unser Moderationsteam es erneut kennzeichnen.

Der Cloudflare R2-Ansatz von kjooleng ist hier der richtige Weg. Es gibt ein paar Dinge zu beachten, wenn du n8n selbstgehostet in China betreibst:

  • n8n außerhalb Chinas hosten: Falls deine n8n-Instanz hinter der Firewall läuft, treffen alle ausgehenden Aufrufe zu Google APIs (nicht nur Drive) auf denselben ETIMEDOUT. Erwäge, n8n auf einem Server außerhalb des chinesischen Festlands bereitzustellen (z. B. HK, Singapore-Region) und Workflows von dort aus zu planen.

  • Alternative für Video-URLs: Falls du nur eine öffentliche URL für Videos brauchst, um diese an Buffer zu übergeben, kannst du auch Alibaba Cloud OSS (aliyuncs) oder Tencent COS nutzen — beide sind zuverlässig in China und unterstützen vorsignierte/öffentliche URLs. Der n8n S3-kompatible Node funktioniert mit beiden.

  • Buffer API-Hinweis: Buffer akzeptiert direkte Video-URLs, daher funktioniert jede öffentliche CDN-URL (R2, OSS, COS) solange sie öffentlich erreichbar ist.

Hey! Dein Verdacht ist absolut richtig.

Die IP 74.125.199.95 gehört Google. Der Fehler connect ETIMEDOUT bedeutet, dass deine n8n-Instanz versucht, einen TCP-Handshake mit Googles API-Servern einzuleiten, aber die Verbindung wird komplett von der Netzwerk-Firewall unterbrochen (sehr häufig bei Beschränkungen vom chinesischen Festland).

Da dein Ziel nur darin besteht, eine öffentliche URL zu erhalten, um sie an Buffer weiterzuleiten, hast du zwei Lösungswege:

Option 1: n8n-Traffic über einen Proxy tunneln (wenn du Google Drive unbedingt verwenden musst)
Wenn du einen Proxy-Server außerhalb der eingeschränkten Region hast, kannst du n8n zwingen, seinen Traffic über diesen zu leiten. Du musst diese Umgebungsvariablen zu deiner n8n docker-compose.yml hinzufügen:

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 # Wichtig, damit lokale n8n-Webhooks nicht über den Proxy laufen

Option 2: Alternative Cloud-Speicher (Sehr empfohlen für Buffer) Wenn das Einrichten eines Proxy zu aufwendig ist, ist der beste Workaround, Google ganz zu umgehen und einen Service zu verwenden, der nicht blockiert wird und Medien besser handhabt.

  • Cloudinary: Das ist ehrlich gesagt die beste Option für Social-Media-Posting. Es hat einen dedizierten n8n-Node, wird normalerweise nicht durch allgemeine Blockierungen betroffen und generiert automatisch optimierte öffentliche URLs für Bilder/Videos. (Workflow: Lokale Datei lesen -
    Cloudinary Upload -
    Cloudinary-URL an Buffer weitergeben)

  • AWS S3 / DigitalOcean Spaces / Bunny.net: Standard-Objektspeicher. Du kannst die Binärdatei dort hochladen (mit dem Bucket außerhalb der eingeschränkten Zone) und eine öffentliche Read-Only-URL konstruieren, um sie an Buffer zu senden.

Der Wechsel zu Cloudinary oder S3 wird für deine automatisierte Social-Media-Pipeline wahrscheinlich viel stabiler sein, als gegen die Firewall um Google Drive-Zugriff zu kämpfen. Hoffentlich hilft dir das weiter!