Caddyfile Error during parsing: Unknown directive

[Homer-Sim]

Hello,

I wanted to add today one more reverseproxy destination. The Cadyfile without these lines is running like a charm. I copied just one existing part changed only url and port but it is ending up in an error.
Did I make a silly mistake which I can not see?

bw.my-wan.de {
#bitwarden
  proxy / 192.168.100.10:8040 {
    transparent
  }
  errors /etc/log/bw_errors.log
  gzip
  tls horst@yahoo.de
}

[Whitestrake (Matthew Fay)]

It looks well formatted to me at a glance.

Can you tell us what error you got, and what Caddy outputs when you run it?

[Homer-Sim]

Sorry for the delay.

After canching Caddyfile with the lines written in post 1 and restarting the container these lines appear in container log and repeating after some seconds

2019/01/18 19:40:09 /etc/Caddyfile:74 - Error during parsing: Unknown directive 'bw.my-wan.de'


exit status 1

It is complaining about the added lines and all others aren’t working …

Is there a letsencrypt limit for for securing domains from a single user?

[Whitestrake (Matthew Fay)]

This is clearly not your entire Caddyfile.

Caddy thinks that you’ve specified bw.my-wan.de as a directive to another site.

This is most likely the result of mistaken formatting further up the Caddyfile.

[Homer-Sim]

For sure it is not. without these lines for bw it is running with not …??

sub.my-wan.de {

#wordpress
proxy / 192.168.100.10:8090 {
transparent
}
log caddy.log
errors caddy.errors
tls horst@yahoo.de
gzip
}

############################################
sub.my-wan.de/gc-bilder {
root /srv/gc-bilder
log /etc/log/gcbilder_access.log
errors /etc/log/gcbilder_errors.log
gzip
}

############################################
sub.my-wan.de/geo {
root /srv/geo

tls off

gzip
}

############################################
ebooks.sub.my-wan.de {
#COPS
proxy / 192.168.100.10:8030
tls horst@yahoo.de
basicauth / g x
basicauth / h y
log /etc/log/ebooks_access.log
errors /etc/log/ebooks_errors.log
gzip

}

############################################
nextcloud.sub.my-wan.de, sub2.my-wan.de {
#nextcloud
proxy / 192.168.100.10:8020 {
transparent
websocket
}
tls horst@yahoo.de
gzip
log /etc/log/nextcloud_access.log
errors /etc/log/nextcloud_errors.log
}

############################################
sync.sub.my-wan.de {
#Syncthing
proxy / 192.168.100.10:8384 {
transparent
}
basicauth / h
errors /etc/log/sync_errors.log
gzip
tls horst@yahoo.de
}

############################################
syncserver.my-wan.de
#firefox sync server
proxy / http://192.168.100.10:5000/token/1.0/sync/1.5 {
transparent
}

############################################
bw.sub.my-wan.de {
#bitwarden
proxy / 192.168.100.10:8040 {
transparent
}
errors /etc/log/bw_errors.log
gzip
tls horst@yahoo.de
}

[Whitestrake (Matthew Fay)]

@Homer-Sim

############################################
syncserver.my-wan.de
#firefox sync server
proxy / http://192.168.100.10:5000/token/1.0/sync/1.5 {
transparent
}

############################################

This section looks like you haven’t encased the site definition in blocks ( { and } ).

[Homer-Sim]

You are my hero!
Sometimes you are so blind … funny that it worked without the new entry

[Whitestrake (Matthew Fay)]

Yeah, interesting.

I guess when the Caddyfile gets parsed, you can put the last site outside of blocks and it’ll parse just fine. The reason you put it in blocks is for this very reason (so the next site doesn’t get interpreted as a directive), so I guess that makes sense.