Reverse Proxy Empty Pages

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

Ubuntu service daemon

a. System environment:

Ubunt 20.04

b. Command:

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

{
	email admin@tld.biz
	http_port 80
	https_port 443
	admin localhost:2019
	log
	storage file_system {
		root /etc/caddy
	}
}

(default) {
}

(tls) {
	transport http {
		tls
		tls_insecure_skip_verify
	}
}

(acl) {
	@acl {
		remote_ip 192.168.76.0/24
		remote_ip 192.168.77.0/24
	}
}
*.tld.biz {
	tls {
		dns ionos 1.2
		resolvers 1.1.1.1
	}
	@archiv host archiv.tld.biz
	handle @archiv {
		import default
		reverse_proxy 192.168.76.204:8462 {
			import tls
		}
	}

	@nextcloud host nextcloud.tld.biz
	handle @nextcloud {
		import default
		reverse_proxy 192.168.76.232 {
		header_up Host {http.reverse_proxy.upstream.hostport}
                header_up X-Forwarded-Host {host}
		}
	}

	@iss host iis.tld.biz
	handle @iss {
		import default
		reverse_proxy 192.168.76.200
	}

	@pf host pf.tld.biz
	handle @pf {
		import default
		reverse_proxy 192.168.76.201
	}

	@post host post.tld.biz
	handle @post {
		import default
		reverse_proxy 192.168.76.204
	}

	@cloud host cloud.tld.biz
	handle @cloud {
		reverse_proxy http://192.168.76.207:8080
	}
	
	@ilo host ilo.tld.biz
	handle @ilo {
		reverse_proxy 192.168.76.198
	}
	
	@proxmox host proxmox.tld.biz
	handle @proxmox {
		reverse_proxy 192.168.76.230 {
			import tls
		}
	}
	
	@bitwarden host bitwarden.tld.biz
	handle @bitwarden {
		reverse_proxy 192.168.76.233
	}
	
	@dasi host dasi.tld.biz
	handle @dasi {
		reverse_proxy 192.168.76.203
	}
}

3. The problem I’m having:

Thansk to the help of this Forum i was abel to set up Wildcard Certs and Reverse proxy to some of my Upstreams.
For example the Cloud and Archiv service work well, at least i i use Firefox and not the Archivs Outlook Plugin but thats a topic for another time.

However some upstreams only return empty pages:
The dasi points to an Buffalo NAS that services only http

4. Error messages and/or full log output:

CUrl -V to dasi:

curl -v 192.168.76.203
*   Trying 192.168.76.203:80...
* TCP_NODELAY set
* Connected to 192.168.76.203 (192.168.76.203) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.76.203
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Vary: Accept-Encoding
< Content-Type: text/html
< Accept-Ranges: bytes
< ETag: "3594469493"
< Last-Modified: Thu, 03 Dec 2020 14:57:46 GMT
< Content-Length: 1326
< Date: Wed, 01 Dec 2021 09:44:29 GMT
< Server: lighttpd/1.4.39
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><!-- InstanceBegin template="/Templates/base.dwt" codeOutsideHTMLIsLocked="false" -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="X-UA-Compatible" content="IE=8;IE=9" />
<meta http-equiv="imagetoolbar" content="no" />
<!-- InstanceBeginEditable name="title" -->
<title>BUFFALO</title>
<!-- InstanceEndEditable -->
<meta name="copyright" content="Copyright (c) 2011 BUFFALO Inc. All rights reserved." />

<!-- CSS:Ext -->
<link rel="stylesheet" type="text/css" href="js/ext/resources/css/ext-all-gray.min.css?_dc=1607007439" />

<script type="text/javascript" src="gruntjs/bootstrap.js?_dc=1607007439"></script>
<script type="text/javascript" src="gruntjs/ext-lang-ja.js?_dc=1607007439"></script>
<script type="text/javascript" src="gruntjs/webui.js?_dc=1607007439"></script>
<script type="text/javascript" src="gruntjs/switch.js?_dc=1607007439"></script>

</head>
<body>
<noscript>
  <img src="./img/top/enable-javascript.png" />
</noscript>
</body>
</html>
* Connection #0 to host 192.168.76.203 left intact

5. What I already tried:

Played around with headers but dont know where a good starting point would be

6. Links to relevant resources:

Doesn’t seem like that request is hitting Caddy, otherwise you’d see Server: Caddy in here.

But if you do get a response and there is HTML at all, then the issue is not with Caddy. No manipulation of the response body will happen when using reverse_proxy (by default, anyway).

Hi francislavoie, thanks for the fast reply.

I used curl from the caddyservers machine to see if i can acces the nas. That was the log provided in the inital post.

if i curl from another machine to das
i.tld.biz i get:

 curl -v dasi.tld.biz
*   Trying 192.168.76.220:80...
* TCP_NODELAY set
* Connected to dasi.tld.biz (192.168.76.220) port 80 (#0)
> GET / HTTP/1.1
> Host: dasi.tld.biz
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://dasi.tld.biz/
< Server: Caddy
< Date: Wed, 01 Dec 2021 15:22:05 GMT
< Content-Length: 0

if i curl with https://dasi.tld.biz :

 curl -v https://dasi.tld.biz/
*   Trying 192.168.76.220:443...
* TCP_NODELAY set
* Connected to dasi.tld.biz (192.168.76.220) 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_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.tld.biz
*  start date: Nov 25 18:51:56 2021 GMT
*  expire date: Feb 23 18:51:55 2022 GMT
*  subjectAltName: host "dasi.tld.biz" matched cert's "*.tld.biz"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  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 0x562cc66a3f90)
> GET / HTTP/2
> Host: dasi.tld.biz
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200
< server: Caddy
< content-length: 0
< date: Wed, 01 Dec 2021 15:25:54 GMT
<
* Connection #0 to host dasi.tld.biz left intact

However if i use a Browser i only get an empty page, empty as in no source code.

i tried adding http://192.168.76.203:80 with no succes.

Okay, that makes me think Caddy didn’t actually handle the request.

Did you reload your config after making changes?

I recommend adding a block like this at the end of your Caddyfile, to catch requests to subdomains you haven’t set up to proxy yet:

handle {
	respond "Unknown domain" 404
}

You can change that to handle it however you want, e.g. use file_server to display an error page, or use abort to close the connection immediately.

Thanks for your reply, ill add this in the morning.

However i just tested arround a bit more and disabled caddy wits systemctl disable --now caddy
and started it “manually” in the directory of the caddyfile. You know so i get the log printed to the console live.
What should i say, proxys worked.
Putting it back up as a service they dont.
Any pointer what the issue can be?

You don’t need to do that. See the instructions here to see how to get your logs:

1 Like

Thanks for the Pointer. It seems

storage file_system {
		root /etc/caddy

had no permissions for the caddy user. Setting it right and the pages load. Thanks again!

1 Like

I’d recommend using the default storage location instead, i.e. /var/lib/caddy/.local/share/caddy. The permissions will already be set up correctly.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.