You are most likely going to be looking at the advanced -> pass-thru settings. Have you consulted GPT? Drop me an private message, maybe I can assist.

@JonathanLee said in Squid alternative for bandwidth control?: @Cabledude remeber to block QUIC or udp over 443 with this setup also because traffic will quickly try to do that after. also you can use access control lists for rep_mime_type too so you can block doh right when its seen with ssl/mitm mode acl deny_rep_mime_doh rep_mime_type ... bingo no giant doh lists it will catch a ton of them its the kill short for doh abuse Thank you Jonathan, much appreciated, though I decided to pass on this tool, so it's pearls for the hogwarths, which is a dutch saying for gifts given to people that don't make the most of it (or even don't care what's given, but that doesn't apply to me: I appreciate your efforts!)

and again... it's all useless for me because the cache still needs manual deletion. The "clear disk cache now" button still doesn't work. It does allow you to use that path with the overlay so kind of a win but same issues as before... so why go and do all of that .... head hits table .....

@Jarester Eita, já começou com respostas geradas por IA logo no dia 02 de Janeiro?

@dauhee Have a look at https://lancache.net/ This project better handles windows updates and steam cache.

Really really strange .. after I filter in the Stats Table to "192.168.1.12", I saw connections to 192.168.1.12:443. Now i change the port from Vaultwarden to 443 and .. I can connect? And in the backend, I connect to port 80? incomprehensible... And there is no port 80 open on the vaultwarden machine: [root@vaultwarden:/opt/vaultwarden]$ ipa|grep ens18 2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 192.168.1.12/24 brd 192.168.1.255 scope global ens18 [root@vaultwarden:/opt/vaultwarden]$ netstat -tulpn Aktive Internetverbindungen (Nur Server) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 667/sshd: /usr/sbin tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 819/master tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 87382/docker-proxy tcp 0 0 127.0.0.1:33233 0.0.0.0:* LISTEN 657/containerd tcp6 0 0 :::22 :::* LISTEN 667/sshd: /usr/sbin tcp6 0 0 :::25 :::* LISTEN 819/master tcp6 0 0 :::5000 :::* LISTEN 644/docker-registry [root@vaultwarden:/opt/vaultwarden]$ and the backend from vaultwarden in /var/etc/haproxy/haproxy.cfg have a "192.168.1.11:80" too...

Solution: after I change the .env.local I have so enter something like: sudo -u www-data php vendor/bin/contao-console contao:setup

It is added to the backend IIS server logging option. It is not receiving it from HAProxy..

Squid can be configured externally, I would love a how to guide on how to do this correctly.

@johnpoz said in Please help to configure HAProxy to serve certifficate on internal LAN too: Yeah - what part do you not understand if you always resolve nextcloud.domain.tld so that it hits your haproxy on your pfsense wan IP are you not getting? You have 2 options - use a different domain internally and always go to nextcloud.publicdomain.tld, or use the same domain internally as external and run into the problem of what IP it resolves to.. Change your local domain to say home.arpa or .internal or atleast something different than the public domain your using to point to pfsense wan IP on the public internet. You are shooting yourself in the foot trying to use the same domain externally as internally. There are ways around it, but they complicate the setup. For example you might be able to use views in unbound as one way to work around the problem. You could use only host entries for all your resources. But then again you run into a problem of using the fqdn for this service, now always pointing to your wan IP.. And that is great when you want to access the service haproxy is doing - but if you want to access that resource on some other service that haproxy doesn't handle - like say simple file sharing.. You are going to have problems. Since you clearly do not understand how any of this works - the simple solution is change the local domain you are using so it is not the same as the public domain you want to use to get to your nextcloud. This tone is outrageous directed at somebody who acknowledged right off the rip that English is not their first language. How many languages do you speak, John? And safely assuming it's only one—English of course—take it from a fellow English native that you'd do well to say more with less words. You otherwise were directing OP in the right direction in my opinion.

@xttenza said in Haproxy backend configuration: backend pass thru http-request set-header Host onesite.com option httpchk GET / http-check send hdr Host onesite.com The above worked for me as well. This is the solution.

mysteriously works again after a gitlab-upgrade. strange ...

@wifi75 your table shows port 80, not 443 for https