New to the community? Start here

Hub showing error 307 temporary redirect

I connected my site to the Hub but I can’t make backups or update the plugins. So basically I can’t manage the site form the hub also, the automated backups don’t work. The performance tab showing 307 temporary redirect error. Can you please fix this error?

Tue, 28 Apr 2020 9:28:53
  • Adam
    • Support Gorilla

    Hello Pascal LECOMTE

    I hope you’re well today and thank you for contacting us!

    I checked the site, The Hub for your site and some internal logs. I also noticed that it’s a “one way” problem: the site is able to “talk to The Hub” but not the other way around. For example, I was able to activate and start (though I cancelled it as it’s a lengthy process) “Managed Backup” in Snapshot directly from the site’s back-end.

    This suggests that it’s a server-side issue.

    The “307 redirect” is a response that (HTTP status code) that The Hub receives from the site/server when it’s trying to “talk to it”. I don’t see any plugins or “flaws” in site configuration that would be doing that and the site is publicly available but still – it responds to some requests that way. I’m saying “some requests” and not “all” because apparently our Uptime service, for example, is working with it (and it’s sending different requests from separate IPs).

    That said, please get in touch with your host and ask them if there are any limitations/firewall/similar filtering or security tools that could possibly be blocking some of the requests. Host might need to look into access logs and white list requests from us but as a first step, please make sure that all the following IPs are white-listed in every possible security/firewall tool that might be related (site, hosting, CDN – if the domain is directed through any CDN). Mostly that would be hosting, though:

    18.204.159.253
165.227.66.214
45.55.78.242  
35.171.56.101 
192.241.140.159
104.236.132.222
192.241.148.185
34.196.51.17  
52.57.5.20

    If white-listing these IPs doesn’t help and your host confirms there’s no other “filters” or similar “lockouts” that could be related to that, please let me know and we’ll investigate it further to make it work.

    Kind regards,
    Adam

  • Adam
    • Support Gorilla

    Hello Pascal LECOMTE

    Thank you for response!

    Can you give us the entire error in your log if it’s possible and the way you tries to connect to the website to investigate in our server ?

    I don’t have any more information on the error than we already discussed here, I’m afraid. Our internal Hub log only states that

    There was an “error” on “remote call” from “hub” for the reason of “We got an unexpected response from your website: 307 Temporary Redirect”

    This is pretty much all I can see, apart from dates and the site name of the site that it applies to.

    My point, when mentioning Hub logs, was mostly that I can confirm there that the error does happen (so it’s not some sort of Uptime UI (user interface) failover or a temporary issue with Uptime check servers) and that it’s response from your site/server when Hub makes a call to it.

    As for “how we trie to connect” – that depends. An Uptime service issues a HTTP HEAD request to the site address that’s registered with the Hub, every 2 minutes. A HTTP HEAD request is pretty much the same as a regular GET request, except it only asks for HTTP headers instead of entire page.

    It should be no different to the server than a standard browser visit, except it’s from specific IPs, it doesn’t need entire page to be returned and it’s quite frequent. So that might also be worth checking with the host – if they are not blocking HEAD requests or putting some “rate limits” on requests.

    Most other connections would be just standard PUT/GET HTTP requests over standard HTTP protocol (SSL secured of course) and ports, over any of the IPs that I shared with you, depending on the service.

    However, I just noticed yet another thing that might be related here. If you look into “Tools -> Site Health” page on your site, you’ll notice that there’s the issue reported that Yoast can’t determine if the site can be indexed or not because:

    Détails de l’erreur : cURL error 28: Operation timed out after 5001 milliseconds with 0 bytes received (http_request_failed)

    That basically means that Yoast tried to “scan’ your site (so basically your WordPress tried to “connect to itself”:wink: to check if it is allowed to index it and it also couldn’t fetch it because there was no timely response to request. The “cURL” request is similar to the way we would be trying to connect to the site and that error means that in fact your server can’t even fetch your site that’s hosted on it.

    So yet another thing to investigate server-side would be if cURL library is up to date on server, if OpenSSL is properly installed and up to date and if it uses valid and up to date SSL certificates (note: it’s not the same as an SSL Certificate of the site; those are separate certificates that OpenSSL uses – server administrators would be able and should check that).

    Kind regards,
    Adam