[squid-users] Squid going through another forward proxy
Hector Chan
hectorchan at gmail.com
Fri Nov 14 05:22:44 UTC 2014
Hi Amos,
> those lines you specify above go in (C). *if* they are needed at all.
But I don't have control over (C). It's off limits.
> In (B) goes:
>
> cache_peer forward-proxy.example.com parent 3128 0 name=C
>
> acl sendToC dstdomain origin-x.example.com origin-y.example.com
origin-z.example.com
> cache_peer_access C sendToC
The requests reaching (B) (reverse-proxy.example.com) are in the form:
http://reverse-proxy.example.com/goto-origin-x
http://reverse-proxy.example.com/goto-origin-y
http://reverse-proxy.example.com/goto-origin-z
and I have a couple of cache_peer_access acls (urlpath regex) to send them
to origin-x, origin-y, and origin-z. How would the above dstdomain acl
work with these rules?
On Thu, Nov 13, 2014 at 7:38 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 14/11/2014 4:03 p.m., Hector Chan wrote:
> > Ah, I think I have a typo in my question. Originally, I mentioned
> > the following:
> >
> >> the logic of figuring out where to go to lies in (C).
> >
> > What I actually meant is "the logic that figuring out where to go
> > lies in (B)" (not C).
> >
>
> Actually both require that logic. Relative to the traffic each is
> receiving.
>
>
>
> > On Thu, Nov 13, 2014 at 5:14 PM, Hector Chan wrote:
> >
> >> Hi Amos,
> >>
> >> Thanks for your reply. Let's say I have the following cache_peer
> >> lines in (B), and the address for (C) is
> >> "forward-proxy.example.com:3128".
> >>
> >> cache_peer origin-x.example.com parent 443 0 no-query
> >> originserver ssl cache_peer origin-y.example.com parent 443
> >> 0 no-query originserver ssl cache_peer origin-z.example.com
> >> parent 443 0 no-query originserver ssl
> >>
> >> What would be the syntax to configure (B) to use "
> >> forward-proxy.example.com:3128" (C) as the forward proxy to the
> >> origin servers (D) ?
>
> those lines you specify above go in (C). *if* they are needed at all.
>
> In (B) goes:
>
> cache_peer forward-proxy.example.com parent 3128 0 name=C
>
> acl sendToC dstdomain origin-x.example.com origin-y.example.com
> origin-z.example.com
> cache_peer_access C sendToC
>
>
> OR, since you say C is the *only* way to access the Internet you can
> omit the acl and cache_peer_access lines. Which will cause all traffic
> to try and go through C.
>
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUZXkaAAoJELJo5wb/XPRjNaYH/0rD/r4hepby40bDQnLTzJyr
> BP5CY/WP6tqBvavJHpJE41TpRhhx6HilZSWccAnhe5Dk7O+wit2rbp4lxZqXID01
> 6sxzPb6IjXldgXd6vmjCzkK8QiDFdFjEev2+26LAX6cPuQOEuiyzCiFFHzI6TK7c
> lXGqDGbkTmBtIplHVAz/7u4IJlb2TNbT23wkzt6jJHUBYxhhY23g3x1sT4Tc045U
> oseTZnazY+Ehrglf/NdNJfBAkcl71Lp65rxDLvo2ayUNffiXeg6bNtd7oGHyZ0S3
> MMUxsF2XA7kDxgPCtD5qhVFnxnhTKCMawz3gf6PRxRlSqeCxB+FrWx01frblx2s=
> =VsYA
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20141113/0afce38b/attachment.html>
More information about the squid-users
mailing list