Use IP address within Caddyfile for domain name?

1. Caddy version:


2. How I installed, and run Caddy:

Followed instruction for ubuntu in Install — Caddy Documentation

a. System environment:

Mint Linux 21 VM running on widows host

b. Command:

updated Caddyfile in /etc/caddy
caddy runs on startup
when change Caddyfile the run sudo systemctl reload caddy

d. My complete Caddy config:

        log default {
                output file /var/log/caddy/log.json
                format json {
                include http.log.access admin.api
vm-name:8555 {
# {
        reverse_proxy localhost:8055
        tls internal

3. The problem I’m having:

I would like to know if its possible to do this. I know it is not sensible but I would just like to get it to work and once it does it will be useful knowledge but never to be used in real life.

I have a VM running a svelte front end and directus backend. If I open ports on my router (port forwarding) then I can via HTTP connect to the frontend, which contacts the backend and everything is great. Except that it is HTTP and eg firefox will not allow login info to be entered into fields in a HTTP page. (Edge will).

So I run the front end under HTTPS. This works except that there are mixed block errors because https is accessing http data (the backend). So that’s not good as all of the dynamic data is missing.

So I used caddy as a reverse proxy to allow

to pass onto http://8055. And if I run within my network (ie I don’t use but use https://vm-name:8555) then that works.

But (and we at last get to the problem), if I use (so go straight to the backend for testing) then firefox gives me SSL_ERROR_INTERNAL_ERROR_ALERT but not much useful information on that.

In Edge it gives

The connection for this site is not secure sent an invalid response.

So in summary, I know I can use vn-name:8555 in the Caddyfile. Can I use ip-address:8555 - will that work?

4. Error messages and/or full log output:

The only info in the caddy log is where I reload the log.

Yes, this works.

The protocol error occurs when Caddy receives a HTTPS request for a site it isn’t configured to serve. It isn’t managing a certificate for that site (, so it simply doesn’t offer the client a certificate at all. This presents as a protocol error.

To have Caddy manage a certificate for both, so that it can accept requests for either, add both addresses to the site block, e.g.

vm-name:8555, {
  # config
  tls internal

And then accept the self-signed cert in your browser when you navigate to either the IP or the hostname.

Hi @Whitestrake,
still having problems.
I changed the Caddyfile to

        log default {
                output file /var/log/caddy/wolfsberg.json
                format json {
                include http.log.access admin.api
vm-name:8555, {
        # Another common task is to set up a reverse proxy:
        reverse_proxy localhost:8055
        tls internal

Open port 8555 on the router and try in firefox and get

Secure Connection Failed

An error occurred during a connection to Peer reports it experienced an internal error.


    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

But https://vm-name:8555 does work - accept unknown certificate and then directus appears.

I just want to add that if I use https: (or use vm-name instead) which will then call port https:8555 to get the dynamic data from directus listening on http:8055 then data is not retrieved. In the firefox browser console, I get

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at[]=*&fields[]=author.avatar&fields[]=author.first_name&fields[]=author.last_name&fields[]=fred&filter=%7B%22membersOnly%22:false%7D&sort=-publish_date. (Reason: CORS request did not succeed). Status code: (null).
Uncaught (in promise) Error: Network Error

Looking at Reason: CORS request did not succeed - HTTP | MDN there is - possible causes

  • Trying to access an https resource that has an invalid certificate will cause this error.
  • Trying to access an http resource from a page with an https origin will also cause this error.

And I am doing both of these things. So is my set up not going to work because I have a browser retrieves the frontend, runs javascript to get dynamic data over the network which is https with an invalid certificate?

This happens whether I go outside of the router (so use or use vn-name.

With Caddyfile:

➜ cat Caddyfile {
  respond "Hello!"
  tls internal

I was able to get a good result:

➜ curl

Just to be absolutely sure, here, could you confirm…

Is equal to here?

The hostname you type in the browser address bar must match the site address you write in the Caddyfile.

If CORS is involved, your prospects are dim for getting this working. The entire purpose of CORS is to make this kind of hackery very difficult or impossible - to protect clients from insecure systems.

To make things easy here, what you want is for all requests to go through Caddy, including requests for the backend, so that Caddy can put HTTPS up in front of it all. That might involve some configuration of your frontend to point subsequent backend requests at the right place, but I’m not familiar with the app in question.

Also, you might want a valid, trusted certificate, rather than a self-signed one. That would neatly preclude IP address targets, as you can’t (easily) get a publicly trusted HTTPS certificate for these.

1 Like

Hello @Whitestrake,
So much for my cunning plan to hide my external IP address!! Fortunately it does change on a regular basis.
And is quicker to write.

The front-end does point to caddy for the backend (either https://vm-name:8555 or and those values are in the directus env CORS_ORIGIN value.

I know this works using http for both ends but then it only works with Edge (which warns but doesn’t forbid) whereas Firefox forbids sending user input over http.

Getting a proper certificate rather than self certificate is a good idea.

I think another thing I need to do is create a table of what works and what doesn’t because it is all getting rather messy.

If this is the case, we should expect zero instances of this:

Since both the frontend and the backend are accessed via HTTPS, via Caddy. That also knocks out the CORS issue with accessing HTTP resources from HTTPS origins. That leaves you only with the issue of getting a valid certificate for your site, which means, hopefully, getting one should see you with a working setup?

1 Like

Just to clarify; the backend is reached via caddy (https:8555 to http:8055) but the front end is direct, no caddy, at https:3000.

Are you still getting mixed content errors, then?

Having investigated further, I suspect that https is not going to work with my setup. svelte will deliver the https but the browser will not allow directus data to be fetched via https delivered via caddy with an internal certificate.
Caddy does work for accessing directus directly.

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