Vimeo Embed not working on my site due to Vimeo server IP blacklisting

If it works here but not there, something in your site configuration has to be different. The link also works on my Digital Ocean hosted Discourse, which I just updated to absolute latest to make sure. I also made the post in the staff category to match your private post example, not that it should have mattered:

I wonder what the configuration difference could be, since it works here on meta, on try, and on my self hosted Discourse just fine?

It is possible vimeo has blacklisted your server or your server IP ranges. One way to tell this is the case, is if other video oneboxes work fine (youtube, etc) and other types of oneboxes.

1 Like

Would there be an easy way for us to find out?

Would the browser console reveal any clues as to the cause? Could we catch a response from Vimeo that might indicate some kind of blacklisting? I wonder why they’d do that though, we’re only a small low-traffic site compared to others :man_shrugging:

It’s only Vimeo videos, YouTube et al are all working fine.

I was able to repro this issue on one of our DigitalOcean hosted instance.

Ran this in rails console:

[1] pry(main)>"", verbose: true).resolve
=> nil

… and in the /logs saw this warning message:

FinalDestination could not resolve URL (status 403):

It seems like Vimeo is blocking a subset of DigitalOcean IPs and is returning 403 error. I am not sure how to handle this case.


My browser console shows a 404, unsure if it’s related:

Our Discourse is indeed on a Digital Ocean droplet :confused:


I am seeing that as well, that is the onebox controller response and is not coming from Vimeo directly.


I suspected as much :confused:

And sure enough, using wget on my DO droplet also confirms:

xx@xx:~# wget
--2019-09-16 14:16:25--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2019-09-16 14:16:25 ERROR 403: Forbidden.

Whereas wget on my home PC works fine:


--2019-09-16 15:16:56--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 115631 (113K) [text/html]
Saving to: '65107797'

65107797         100%[=============>] 112.92K  --.-KB/s    in 0.07s

2019-09-16 15:16:57 (1.60 MB/s) - '65107797' saved [115631/115631]


I’ve just opened a support ticket with Vimeo asking if they can exclude our IP address from their somewhat wide blanket ban.

I’m not expecting much response or support from them though :confused:

But in case others here are also affected, I’ll post an update here if/when they get back to me.


I’m very interested too. I have the same issue on my discourses forum…

1 Like

I was going to wait until fully resolved, but a quick update for you all.

Vimeo support did indeed confirm a blanket-ban on many different cloud hosting provider IP ranges.

I asked to be whitelisted / excluded from that ban. I had to jump through several hoops and answer some questions on a form about intended usages etc, but yesterday I had a message from them that said they were speaking to their “Security and Reliability Engineering Team” to whitelist our IPs.

I’ll post a proper update/details here when fully resolved.


Fair play to Vimeo support, they have indeed whitelisted our Digital Ocean droplet IP address.

And in testing, the same URL as used in this thread, you’ll see it failed in all previous tests and worked perfectly on the last one just now:

Just to expand on this, I had to create a public post on our Discourse, with the failed embedded video URL visible and send them the URL to said post. I marked that post as unlisted.

I also had to verify that the IP address of our site was static (seemed an odd question).

And lastly, I had to provide a few paragraphs explaining what our intended use case was for wanting to embed videos in our site.

The whole process took just three days from start to finish :+1:t2:


So @PaigeLynn I am curious how you ever got this working, since Vimeo was clearly blacklisting entire server IP ranges. It had nothing to do with Discourse at all.

1 Like

Very useful post thanks!
I’ve just had exactly the same issue on a server that in the past has been working fine. Vimeo was actually quite responsive & IPs had been opened up again within 12hrs of my first support request. I’m on DigitalOcean

For anyone raising this issue to vimeo, My request pretty much contained the following:

I’m not able to embed Vimeo videos on my site and I’ve run a couple of tests and think my server address is being blocked.

and then I used the wget test @Richie showed below using my own server responses.


Excellent news :+1:t2:

And for completeness, when using wget on my Digital Ocean instance now, the 403:Forbidden error is now gone:

xx@xx:~# wget
--2019-10-06 15:25:19--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125476 (123K) [text/html]
Saving to: 65107797

65107797                                          100%[========================>] 122.54K  --.-KB/s    in 0.007s

2019-10-06 15:25:20 (17.4 MB/s) - â65107797â saved [125476/125476]

I’m having the same issue. Vimeo after many responses back and forth wrote this. I don’t understand the response and I don’t know how to fix it.

From Vimeo Support:

Understood, thanks for the information. I did some research about the Onebox plugin, and from what I can tell from the plugin’s GitHub page, it’s retrieving metadata from Vimeo using unsupported methods.

To retrieve metadata from Vimeo, we recommend using our oEmbed implementation. The Onebox developer will need to update their plugin to support oEmbed. Additionally, usage of oEmbed will not be affected by the IP address ban.

Sorry to say, but since the plugin is retrieving metadata from Vimeo in an unsupported way, we cannot whitelist your IP address at this time. To work around the IP block, you’ll need to request Onebox update their plugin, or seek out another plugin that utilizes oEmbed to get Vimeo metadata.

1 Like

Are you able to wget the Vimeo page from the server itself, to confirm the IP address is blacklisted?

1 Like

I don’t know how to interpret this but it looks blocked to me!

Vimeo thinks that the developer needs to update the onebox plugin

1 Like

Hi, I’m Tommy and I’m a developer support specialist at Vimeo – I recently replied to Steve above, and in all likelihood handled IP address whitelist requests from other users who have posted here in the past few weeks. I wanted to provide some information here so that developers and website owners encountering Vimeo errors related to IP blocks know what to expect and how to resolve their issue.

We have some blocked IP addresses on some cloud host providers. For security purposes we cannot publicly disclose which cloud hosting providers or which IP addresses on those providers are banned.

After making some changes on our backend last week, human users (such as clients using a VPN hosted by one of these cloud providers) should be able to solve a CAPTCHA challenge to gain Vimeo access and temporarily whitelist their IP address. Whitelisting IP addresses manually by contacting us at Vimeo should no longer be necessary, though we’re always happy to clarify and guide you in the right direction.

What seems to be happening on Discourse, and specifically when using the Onebox library, is that Onebox tries to get Vimeo video metadata in an unsupported way (based on what I’m seeing here). Officially, Vimeo doesn’t support the og tags for widespread public consumption. Instead, we recommend using our oEmbed implementation to get that same metadata (embed code, thumbnail image, video url, etc.)

Using oEmbed or the full-fledged Vimeo API is generally not subject to the same IP block – using oEmbed or the Vimeo API are the only supported methods for servers to get and interact with data on Vimeo. Discourse will need to modify the Onebox library accordingly to use oEmbed instead.

The Vimeo oEmbed implementation is documented here: Working with oEmbed: Embedding Videos | Vimeo Developer


Thanks for letting us know what’s going on.

I don’t know how to ask this without sounding rude, but if you don’t support OG tags, why send them?

This has worked for years and just stopped. Discourse does have site-specific one-boxes for other sites, so presumably someone will do that, but here’s what my client, who has a video-intensive site with lots of vimeo content, said:


I’m not an engineer here so I can’t comment on changing the onebox implementation myself, but I do agree that it makes it very difficult for developers to know you don’t support something that’s supposed to be an open standard for open use.


So you’re blocking the use of some (of your self-supplied) metadata on some IP addresses of some cloud providers. People who run into issues can solve this by simply using other metadata, or other IP addresses, or other cloud providers.

There is only one thing left to ask.

Why? In heaven’s name, why?