Enabling proxy results in 418 Teapot error

General
1

Hello!

I’ve just purchased a domain, setting the root and www records to direct access and it works perfectly. If I enable proxied status, cloudflare returns a 418 (“I’m a teapot”) error. I’ve got 3 other domains with the same setup and are working perfectly using proxied status.

I can’t find any documentation which would explain why cloudflare would return a 418 error at all, my initial thoughts was this was some whimsical response to a percieved attack, however there’s no security events listed that would correlate with the response I am seeing.

Any ideas?

Thanks!

3

This is not a real status code, rather an April fools’ joke

And I doubt you will as per above.

What is the configuration you are currently using?

1 Like
4

Exactly my point regarding the response! Hence my surprise.

I registered the domain yesterday, it’s a .org TLD. I have an A record for the root pointing to the IP of the hosting location and a CNAME record for “www” pointing to another domain I own (which in turn points to the same location as the root A record). This is the same setup as 2 other domains I am using.

The origin server receives no requests at all when proxied status is used, implying it’s not getting past cloudflares proxy services. As stated in my original message disabling proxied status results in everything working perfectly.

The domain is whitfordvillagehall.org, a curl request below:

user@debian:~$ curl -v https://www.whitfordvillagehall.org
*   Trying 172.67.202.121:443...
* Connected to www.whitfordvillagehall.org (172.67.202.121) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=whitfordvillagehall.org
*  start date: Aug 17 18:45:23 2023 GMT
*  expire date: Nov 15 18:45:22 2023 GMT
*  subjectAltName: host "www.whitfordvillagehall.org" matched cert's "*.whitfordvillagehall.org"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1P5
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x559927dfc2c0)
> GET / HTTP/2
> Host: www.whitfordvillagehall.org
> user-agent: curl/7.74.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 418
< date: Fri, 18 Aug 2023 11:42:15 GMT
< content-length: 0
< cf-cache-status: DYNAMIC
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=VTCDxIpcsgOkG0AJ3K8vdeukyBFOFrf6OQ5CQFLwLbSMjqBxobAa2xRcKqrjRPUHDpwnumjwPsYhMtW1Z4aDxlZYgSwdLOSGL6tv4U8tQO9x%2FaZE6nsRMEh7qf5ogA9g4mE5S%2BEutC5YKIolr24%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 7f89e473eacc7697-LHR
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host www.whitfordvillagehall.org left intact
user@debian:~$
5

Is the aim of this domain (whitfordvillagehall.org) to act as a redirect? Or are you expecting it to load content?

6

It should load content, it’s hitting the same origin server as the other domains but there’s configuration in place to reverse proxy traffic to that domain to a different backend service. This works, since disabling the proxy results in the correct behaviour.

7

Honestly I don’t know.

I suspect Cloudflare wouldn’t return a 418 I'm a teapot—though the mind of an engineer is a place I don’t want to go—and wonder if it is a misconfiguration on the server that is causing it—I cannot say because I don’t know what setup you have; though I do note you say it works when not proxied.

Given the same response from both apex and www—one an IP the other a CNAME—adds to the believe it isn’t a Cloudflare issue.

Happy if others—or yourself—are able to prove my suspicions incorrect.

8

I believe you’re right, I’ve tried pointing the records towards something entirely different, (tried neverssl.com) and that’s being proxied correctly.

I therefore assume that my reverse proxy is treating SSL request from cloudflare differently to the other domains I have hosted behind it, but it’s narrowed down the search radius at least!

9

I found the problem - thanks for reinforcing the belief that this wasn’t a cloudflare issue!

In case anyone else has this, the problem is as follows: Client performs HTTP/HTTPS request to cloudflare (if HTTP, cloudflare auto-redirects to HTTPS), cloudflare then performs a HTTP request to the backend. An incorrect rewrite rule in the backend was causing an infinite loop within the reverse proxy (effectively http getting redirected to HTTP). This loop results in the error being fired back to cloudflare as the reverse proxies way of breaking out of the loop and protecting itself. Any tests performed previously (i.e. without the proxy) were to HTTPS endpoints (no redirect needed) which worked. Any tests within browsers resulted in browsers attempting to use HTTPS by default, again resulting in no problems.

The reason other domains were not impacted is I had previously enabled strict HTTPS on those domains, resulting in cloudflare performing a HTTPS request to the backend therefore not hitting the rewrite rule. The fix here was to do the same for this domain (but I should fix the rewrite rule too).