Making one site local-only

Help
1

1. Caddy version (caddy version):

v2.1.1

2. How I run Caddy:

caddy start with Caddyfile

a. System environment:

Ubuntu 18.04.4 LTS

b. Command:

caddy start # doh ...

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

{
  email ...
}

git.jeelabs.org {
  @local {
    remote_ip 192.168.188.0/24
  }
  reverse_proxy @local localhost:3001
  log {
    output discard
  }
}

[...]

3. The problem I’m having:

I have a few active websites, mostly static, and NextCloud, and Gitea.

The Gitea site is being flooded with requests from numerous sites since yesterday, which brings that server to its knees (10…100 req/sec).

I want to restrict access to that site only, so it can still be used locally. Restricting by remote_ip doesn’t work, because of the https certificate.

4. Error messages and/or full log output:

N/A

5. What I already tried:

I tried tls internal, but I can’t seem to make Firefox accept that.

6. Links to relevant resources:

N/A

2

Try wrapping your reverse_proxy in a handle block. See How to stop remote access - #2 by Whitestrake.

git.jeelabs.org {
  @local {
    remote_ip 192.168.188.0/24
  }
  handle @local {
    reverse_proxy localhost:3001
  }
  log {
    output discard
  }
}
3

Thanks for the tip, I didn’t know about handle ....

It seems like the right way to do things, but I’m not getting through. Could it be that http/2 is messing things up? I’d be fine with just 1.1, but haven’t figured out how to limit that either (have only worked with Caddy v1 until yesterday).

UPDATE: Hm, this may need “DNS validation” for the wildcard certificate stuff, since there are more sites. Yikes, I’ve got some more reading up to do …

4

Ok, solved - my router was making the git.jeelabs.org look like it came from the outside IP address. I can add an entry in each of my local machine’s /etc/hosts files to get around that. Then your solution works.

Many thanks!

1 Like
5

FYI this can be simplified to following; handle isn’t necessary if only wrapping a single directive, and you can make use of single-line named matchers:

  @local remote_ip 192.168.188.0/24
  reverse_proxy @local localhost:3001

So in other words, your original Caddyfile was fine as-is, it was just a DNS issue you were encountering, I think.

As an aside, it would probably be better consider blocking requests from outside using a firewall like ufw which will prevent requests from hitting Caddy altogether, reducing load significantly. This could cause you trouble with Let’s Encrypt though, since they don’t publish a list of IPs to whitelist. Just something to consider.

1 Like
6

Thanks, yes, I think that’s indeed the correct analysis: DNS put me on the wrong foot.
Current load is acceptable, so I’ll leave it for now, but thank you for the ufw tip.

FWIW, I did end up using a not rule w/ handle, because I found a way to filter the main load while allowing basic browse access to the main parts of the site. So it’s now partly back up. Good enough (merely puzzling as to why this utterly nonsensical spidering is even being carried out).

Thanks again for the help - it’s great to have access to such good guidance in this forum.

2 Likes
7

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