I am trying to automate social media posting to Facebook, Instagram, X, YouTube, and TikTok using n8n and Buffer. My original plan was to read local files, sync them to Google Drive for a public URL, and then pass that URL to Buffer. However, I am unable to authenticate n8n with Google Drive, getting a connection timeout error.
Error: connect ETIMEDOUT 74.125.199.95:443
More details
Failed to connect. The window can be closed now.
I suspect this is due to network restrictions from mainland China?? but all my other stuff runs very well.
How can I resolve this connection issue, or are there alternative ways or workarounds to achieve the same goal of getting a video URL for Buffer without relying on Google Drive?
The most robust and accessible alternative for users in your region is Cloudflare R2​. It is an S3-compatible object storage service that is generally much more accessible and provides a straightforward way to generate public URLs.
Follow this guide:
1. Set up Cloudflare R2
Log in to your Cloudflare dashboard → R2 → Create Bucket​.
Give your bucket a name (e.g., social-media-assets).
Crucial Step: Go to the bucket Settings → Public Access​.
Either enable the R2.dev subdomain (for testing) or connect a Custom Domain (recommended for production). This gives you the base URL (e.g., https://pub-aaa.r2.dev or https://cdn.yourdomain.com).
2. Configure n8n S3 Node
Since R2 uses the S3 protocol, use the S3 node in n8n:
Credentials: Create an S3 credential.
Access Key ID & Secret Access Key: Get these from the R2 “Manage R2 API Tokens” page in Cloudflare.
Endpoint: Use your R2 S3 endpoint (e.g., https://<accountid>.r2.cloudflarestorage.com).
Operation:Upload a File.
Bucket:social-media-assets.
File Content: Pass the binary data from your local file read node.
3. Construct the Public URL
The S3 node uploads the file, but it doesn’t “return” the public URL automatically. You can easily construct it using a Set node or an expression: https://your-public-endpoint.com/{{ $json.key }}(Where {{ $json.key }} is the filename/path returned by the S3 node).
4. Pass the URL to Buffer
Now, use the HTTP Request node to call the Buffer API:
Hey @Aria the timeout is the Great Firewall, not n8n. 74.125.x.x is a Google range, and Google APIs including Drive are blocked from mainland China. The OAuth window failing is expected. Your other nodes work because they aren’t hitting Google.
kjooleng’s R2 approach is sound as an architecture, but one thing worth clarifying before you sink time into it: Cloudflare is not a reliable way around the firewall. Cloudflare IPs get throttled and reset by the GFW depending on province and ISP, and the public r2.dev subdomain specifically has a history of being blocked in mainland China. If you go R2, use a custom domain, not r2.dev.
Here’s the part that actually matters for your setup though. Only one leg of this has to cross the firewall: your n8n box uploading the file. Buffer pulls the URL from its own servers outside China, so a URL being blocked inside China does not affect Buffer at all. That flips the question. It’s not “is the URL reachable from China,” it’s “can my n8n instance reach the storage endpoint to upload.”
So before committing:
Test the upload endpoint from your n8n host. For R2 that’s curl -I https://<accountid>.r2.cloudflarestorage.com. If it hangs, the upload will hang too.
If it’s flaky, skip the fight and use a China-native object store: Alibaba Cloud OSS or Tencent COS. Both are S3-compatible, both give you a public URL Buffer can fetch, and neither depends on GFW conditions holding steady day to day. For someone operating inside the mainland, that’s usually the lower-maintenance path.
Same pattern either way: upload the file, build the public URL, pass it to Buffer. The only real decision is which storage endpoint your n8n box can talk to reliably.
alibaba oss or tencent cos is the right direction since you’re inside the great firewall, but test the actual URL from outside China too before wiring it in. some regional CDNs look public locally and then the scheduler’s servers can’t reach them, which just flips the connectivity problem around.
whatever storage you choose, the URL has to stay public and non-expiring when the scheduler fetches it, not only when you test it 10 minutes earlier. signed URLs expiring before publish is a really common failure that looks like a platform bug.
i hit the same class of issue running blotato from n8n. the root cause was a preview/temp URL instead of a real public file. one useful diagnostic: media-fetch errors sometimes show the first character of the response, so an e can point to an expired URL. and if Google Drive comes back later, use the drive.usercontent.google.com/download format with the file ID. the normal /view link won’t work for this.
We have taken a look at this issue and are unable to confirm that this is a bug, For now we have closed the internal ticket but if it starts to look like it is a bug our moderation team will flag this again.
The Cloudflare R2 approach from kjooleng is the right path here. A few things to note if you’re running n8n self-hosted inside China:
Host n8n outside China: If your n8n instance is inside the firewall, all outbound calls to Google APIs (not just Drive) will hit the same ETIMEDOUT. Consider deploying n8n on a server outside mainland China (e.g., HK, Singapore region) and scheduling workflows from there.
Alternative for video URLs: If you only need a public URL for videos to pass to Buffer, you can also use Alibaba Cloud OSS (aliyuncs) or Tencent COS — both are reliable inside China and support presigned/public URLs. The n8n S3-compatible node works with both.
Buffer API note: Buffer accepts direct video URLs, so any public CDN URL (R2, OSS, COS) will work as long as it’s publicly accessible.
The IP 74.125.199.95 belongs to Google. The connect ETIMEDOUT error means that your n8n instance is trying to initiate a TCP handshake with Google’s API servers, but the connection is being dropped entirely by the network firewall (very common with mainland China restrictions).
Since your goal is just to get a public URL to pass to Buffer, you have two ways to solve this:
Option 1: Tunnel n8n traffic through a Proxy (If you must use Google Drive)
If you have a proxy server located outside the restricted region, you can force n8n to route its traffic through it. You need to add these environment variables to your n8n docker-compose.yml:
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 so local n8n webhooks don't route through the proxy
Option 2: Alternative Cloud Storage (Highly Recommended for Buffer) If setting up a proxy is too much hassle, the best workaround is to bypass Google entirely and use a service that isn’t blocked and handles media better.
Cloudinary: This is honestly the best option for social media posting. It has a dedicated n8n node, isn’t typically targeted by general blocking, and automatically generates optimized public URLs for images/videos. (Workflow: Read Local File → Cloudinary Upload → Pass Cloudinary URL to Buffer)
AWS S3 / DigitalOcean Spaces / Bunny.net: Standard object storage. You can upload the binary file there (hosting the bucket outside the restricted zone) and construct a public read-only URL to send to Buffer.
Switching to Cloudinary or S3 will likely be much more stable for your automated social media pipeline than fighting the firewall for Google Drive access. Hope this helps!