Für eine bestehende DigitalOcean-Load-Balancer-Ressource bleibt der Proxy-Bytestrom des Clients mit passenden TCP-Protokollen erhalten:

forwarding_rule {
  entry_port      = 3128
  entry_protocol  = "tcp"
  target_port     = 3128
  target_protocol = "tcp"
}

Behalten Sie das tatsächliche Ziel, Netzbeschränkungen und Zustandsprüfungen um dieses Fragment herum bei. Der Client nutzt die Adresse des Load-Balancers, und Squid empfängt den Strom an seinem Listener.

Ein Forward-Proxy akzeptiert HTTP-Ziele in absoluter Form und CONNECT für HTTPS. Der gewöhnliche HTTP-Load-Balancing-Modus muss diese Gespräche ausdrücklich unterstützen; den Listener HTTP zu nennen belegt diese Kompatibilität nicht.

Prüfen Sie mehr als den Port: Eine TCP-Zustandsprüfung belegt die Annahme, während ein authentifiziertes CONNECT zu einem erlaubten Ziel den Proxy-Vertrag ausübt.

Prüfen Sie die Quelladresse, die Squid sieht, bevor Sie sich auf die IP-Autorisierung verlassen. PROXY-Protokoll-Metadaten erfordern, falls verwendet, Unterstützung an beiden Enden und fügen Bytes vor der Proxy-Anfrage hinzu. Leeren Sie aktive Tunnel während der Zielwartung bewusst; das abrupte Entfernen ihres Prozesses unterbricht sie.

Ähnliche Artikel