Reyuki.site too many redirect

Zero Trust Cloudflare Tunnel
1

What is the name of the domain?

reyuki.site

What is the error number?

301

What is the error message?

ERR_TOO_MANY_REDIRECTS

What is the issue you’re encountering

I encounter ERR_TOO_MANY_REDIRECTS when visit control.reyuki.site

What steps have you taken to resolve the issue?

I have tried enable full encryption mode and as per my understanding and my assumption, the problem is, when the client send a https request, cloudflare somehow send http request to the origin server and forward 301 response back to the client? I don’t understand why full encryption mode behave like this, my assumption might misleading

I have checked and visit the site on local network and it works with the self-signed cert warning

What are the steps to reproduce the issue?

visit control.reyuki.site

Screenshot of the error

image.png
image.png826×502 13.6 KB

2

Alright, the problem of redirect is found, I configure http instead of https on the zero trust cloudflare tunnel dashboard

the issue now is the cloudflare reported 502 error page, how to debug this problem?

3

on the local, it works

  curl -s -v -k -o /dev/null https://server:9090/
* Host server:9090 was resolved.
* IPv6: (none)
* IPv4: 192.168.18.37
*   Trying 192.168.18.37:9090...
* Connected to server (192.168.18.37) port 9090
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [906 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: O=7d33754bfffd400ea198f7de22316f4e; CN=server
*  start date: Sep 14 12:02:37 2024 GMT
*  expire date: Oct 14 12:02:37 2025 GMT
*  issuer: O=7d33754bfffd400ea198f7de22316f4e; CN=server
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: server:9090
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
{ [5 bytes data]
< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Security-Policy: connect-src 'self' https://server:9090 wss://server:9090; form-action 'self' https://server:9090; base-uri 'self' https://server:9090; object-src 'none'; font-src 'self' https://server:9090 data:; img-src 'self' https://server:9090 data:; block-all-mixed-content; default-src 'self' https://server:9090 'unsafe-inline'
< Set-Cookie: cockpit=deleted; PATH=/; SameSite=strict; Secure; HttpOnly
< Transfer-Encoding: chunked
< Cache-Control: no-cache, no-store
< X-DNS-Prefetch-Control: off
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< Cross-Origin-Resource-Policy: same-origin
< X-Frame-Options: sameorigin
<
{ [5 bytes data]
* Connection #0 to host server left intact
4

the problem resolved, see the details on github issue

but I think it would be more safe to access through ssh instead of this way… so I ended up using ssh -N -C -L 8080:127.0.0.1:9090 user@addr -p <ssh_port_number>

5

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.