Connecting to Synology NAS with DSM 7

1. Caddy version (caddy version):


2. How I run Caddy:

a. System environment:

  • in a LAN server inside docker
  • LAN server is behind pfSense v2.5.1-RELEASE.
  • domain DNS is managed in Cloudflare:
  • I have installed a Let’s Encrypt certificate in Synology for domain (because I couldn’t get Caddy to automatically get a cert for this subdomain for some reason. Caddy gets certs fine for all other subdomains in the Caddyfile)
  • Port forward in pfSense:
    • port 443 / 80 / 5001 to LAN server

b. Command:

Docker Compose file

    container_name: caddy
    image: caddy
      - PUID=1000
      - PGID=1000
      - 80:80
      - 443:443
      - 2019:2019
      - 5000:5000
      - 5001:5001
    restart: unless-stopped
      - /home/user/caddy/config:/config
      - /home/user/caddy/data:/data
      - /home/user/caddy/Caddyfile:/etc/caddy/Caddyfile
      - /home/user/caddy/public:/usr/share/caddy

c. Service/unit/compose file:

Not sure… maybe N/A for me?

d. My complete Caddyfile or JSON config:

} {
# Calibre {
# Wireguard {
# Booksonic {
# Synology {
  # reverse_proxy # line commented if the above line isn't

3. The problem I’m having:

I’m trying to connect to the NAS web login page with HTTPS but I’m getting the errors below.

4. Error messages and/or full log output:

curl -v
# shortened for clarity
400 The plain HTTP request was sent to HTTPS port
400 Bad Request
curl -v
# or
curl -v
# shortened for clarity
Sorry, the page you are looking for is not found.

So it seems that the response from both is coming from Synology which means that it’s at least reaching there somewhat. But obviously, not everything is working.

5. What I already tried:

  • inside Synology, disable switching HTTP connections to HTTPS
  • inside Cloudflare tried but none worked:
    • switching to different SSL/TLS encryption mode
      • usually is Full(strict)
      • tried all other modes e.g. Off, Flexible, Full
    • switching subdomain from Proxied to DNS Only
  • I have been running this setup with Caddy for >1 year and all other subdomains are working (they have different requirements of course)
  • What works:
    • port forward 80/443/5001 to NAS internal IP and in browser connect to NAS login page at
    • port forward 5001 to NAS internal IP and in browser connect to <EXTERNAL_IP:5001>
      • I get a certificate error (expected, as it’s IP and not the domain that the cert is issued for) that I can ignore and login

6. Links to relevant resources:


Looks like the request is hitting some nginx server, not Caddy.

Please don’t shorten this, the details are usually relevant.

Sorry. Here’s the screenshot:

And here’s the screenshot for and

Yes I think the response is from the NAS. i.e. both requests are hitting the NAS.

Please post the full output of curl -v. Is there Server: Caddy in it? That would tell us if it’s a response proxied through Caddy or not.

Oh sorry, here it is without my IP.

Yes, Server: Caddy is in the response.

*   Trying <IP_ADDRESS>...


* Connected to (<IP_ADDRESS>) port 443 (#0)

* schannel: SSL/TLS connection with port 443 (step 1/3)

* schannel: checking server certificate revocation

* schannel: sending initial handshake data: sending 188 bytes...

* schannel: sent initial handshake data: sent 188 bytes

* schannel: SSL/TLS connection with port 443 (step 2/3)

* schannel: failed to receive handshake, need more data

* schannel: SSL/TLS connection with port 443 (step 2/3)

* schannel: encrypted data got 3465

* schannel: encrypted data buffer: offset 3465 length 4096

* schannel: sending next handshake data: sending 93 bytes...

* schannel: SSL/TLS connection with port 443 (step 2/3)

* schannel: encrypted data got 195

* schannel: encrypted data buffer: offset 195 length 4096

* schannel: SSL/TLS handshake complete

* schannel: SSL/TLS connection with port 443 (step 3/3)

* schannel: stored credential handle in session cache

> GET / HTTP/1.1

> Host:

> User-Agent: curl/7.55.1

> Accept: */*


* schannel: client wants to read 102400 bytes

* schannel: encdata_buffer resized 103424

* schannel: encrypted data buffer: offset 0 length 103424

* schannel: encrypted data got 418

* schannel: encrypted data buffer: offset 418 length 103424

* schannel: decrypted data length: 389

* schannel: decrypted data added: 389

* schannel: decrypted data cached: offset 389 length 102400

* schannel: encrypted data buffer: offset 0 length 103424

* schannel: decrypted data buffer: offset 389 length 102400

* schannel: schannel_recv cleanup

* schannel: decrypted data returned 389

* schannel: decrypted data buffer: offset 0 length 102400

< HTTP/1.1 400 Bad Request

< Content-Length: 248

< Content-Type: text/html

< Date: Sat, 03 Jul 2021 04:37:11 GMT

< Server: Caddy

< Server: nginx



<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>


<center><h1>400 Bad Request</h1></center>

<center>The plain HTTP request was sent to HTTPS port</center>




* Connection #0 to host left intact

Okay, so Caddy is properly proxying the request. In that case, that means you’re proxying Caddy to the wrong port. Your NAS must have two ports it’s serving content on, an HTTP and an HTTPS port. Use the HTTP port instead.

I tried that and I got the response:

“Sorry, the page you are looking for is not found.”

(I can’t post the image as my account doesn’t allow me to post 2 images in a post)

But then this inspired me to check the DSM settings and I removed the “Customized domain”, it was previously

This worked! Though I wonder why…

Thank you for your help and your speedy reply!

Now that I got it to work, I’m curious and would like to ask more questions, if I may:

  1. I thought I configured NAS port 5001 as the HTTPS, and then NAS port 5000 as HTTP. I checked that this seems the case when I connect it locally with the IP address.

Why is it that caddy requires the reverse proxy to use HTTP port?

  1. Caddy isn’t able to automatically retrieve and manage the HTTPS certificate for me for this subdomain, any idea on why this is?

Just noticed my original post and some of my replies have been marked as spam.

What makes them spam?

The system said:

This new user tried to create multiple posts with links to the same domain. All posts from this user that include links should be reviewed.

So I went ahead and restored them.

1 Like

It doesn’t require it, but it’s simplest, and still secure. Since the connection is happening within your network, if you trust all the machines on your network, then it’s safe. See this topic for an explanation:

If you must use HTTPS to proxy, then use https:// in your upstream address to tell Caddy to try to connect with TLS to the upstream.

The issue with proxying over HTTPS is typically trust. If your upstream doesn’t have a trusted certificate (i.e. issued by a well-known public CA) then Caddy can’t trust it and won’t complete the TLS handshake… unless you throw away all security by using tls_insecure_skip_verify transport option, which is “just as secure” as HTTP, as in, not at all. So might as well use HTTP if you don’t want the headache of managing trust internally.

Any logs? I see no evidence of that. If you’re able to connect to with a successful response from Caddy, then you do have a certificate for that domain.


Thank you for your detailed explanation. It really helps me in understanding how Caddy works and increase my networking understanding, and points me in the right direction for further research!

I was thinking that entering would be sufficient. Is that what you mean by upstream? And yes I agree that I don’t need https in my own LAN (which is also the case for my other self-hosted services).

The logs don’t mention anything about getting a certificate for this subdomain. But this might be because I already manually installed a certificate in the NAS (which I did to troubleshoot the connection problem that is now solved). I guess a good test would be to remove that certificate and see what Caddy does. Though the NAS is in heavy use now since it is working so I can’t risk it not working, I guess I’ll have to come back to this test.


By “upstream” I’m talking about the first argument to reverse_proxy. The “upstream” is the thing that Caddy sends the request to, when proxying.

So instead of reverse_proxy, you might do reverse_proxy But like I said, this likely wouldn’t work as-is, you’d need to make sure the correct Host header is sent (since the upstream server probably picks the certificate to use based on the Host header or SNI) and then you’d need to deal with the issue of trust, like I wrote earlier.

Caddy probably issued the cert for in an earlier run. It won’t log issuance if issuance doesn’t happen. And renewal only happens after 2/3 of the lifetime of the cert, i.e. 90 day lifetime, so after 60 days a renewal is attempted. You could look in Caddy’s storage location to find the certificate/key, i.e. in /home/user/caddy/data, your docker volume for /data.

Yep, you could do that. Don’t delete it too often though cause you could hit Let’s Encrypt rate limits (but it’s pretty hard to hit the rate limits, they’re pretty generous Rate Limits - Let's Encrypt and as an aside ZeroSSL has no rate limits).

I didn’t know this was possible. Thanks for pointing this out. And yes it didn’t work for me as you said.
I did find a setting to customize the server header. I’ll need to investigate more on this to (probably w/ the Synology guys) to see how best to do this.

Yes indeed, thanks for the tip!

1 Like

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