<div dir="ltr"><div>
<span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">Thank you for your clarification.</span></span></span></div><div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">But could you please explain in more detail and in my case what needs to be added to "strengthen and ensure" the operation of my solution?</span></span></span></div><div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">The quote from the file </span></span></span>
squid.conf.documented <span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">is not very clear to me.</span></span></span>
</div><div><br></div><div># # # First, mark transactions accepted after aclX matched<br># # acl markSpecial annotate_transaction special=true<br># # http_access allow acl001<br># # ...<br># # http_access deny acl100<br># # http_access allow aclX markSpecial</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">вс, 22 дек. 2024 г. в 22:47, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-12-22 08:13, A. Pechenin wrote:<br>
> The reason and solution were not simple and obvious at first glance.<br>
> I have two providers accessing the gateway, the main and backup <br>
> channels, and automatic switching is configured when the connection on <br>
> the main channel is lost.<br>
> To check, I switched the proxy server to the second channel and the <br>
> problem with partial unavailability of Google services was solved.<br>
> <br>
> I returned it back, used a simple formula in the configuration file with <br>
> subsequent partial adjustment of ipfw.<br>
<br>
Glad you found a solution! Diagnosing problems related to CONNECT <br>
tunnels is difficult because Squid (playing a role of a dumb TCP relay) <br>
is often unaware of problems experienced by clients and origin servers.<br>
<br>
<br>
> # Google via ISP2<br>
> acl google dstdomain .<a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br>
> tcp_outgoing_address REAL_IP_ISP2 google<br>
<br>
Please note that the above configuration usually "works" but is <br>
unreliable and unsupported: tcp_outgoing_address directive does not <br>
support slow ACLs and your ACL named google is a slow ACL.<br>
<br>
For a more reliable solution, consider annotating google-matching <br>
transaction at http_access check time and then using those annotations <br>
at tcp_outgoing_address check time. For a somewhat related example, look <br>
for "markSpecial" in squid.conf.documented or search this mailing list <br>
archives for annotate_transaction discussions.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
> сб, 21 дек. 2024 г. в 20:26, A. Pechenin <<a href="mailto:alexmrrc@gmail.com" target="_blank">alexmrrc@gmail.com</a>>:<br>
> <br>
> This week, when connecting users through a proxy server, some Google<br>
> services became inaccessible, such as Calendar, Translator, user<br>
> profile.<br>
> <br>
> When clicking on the services section in the browser on the Google<br>
> portal, the page does not open and then a connection error is<br>
> displayed. When directly going to the calendar section, the<br>
> connection also hangs for a long time without loading the page. At<br>
> the same time, the Google home page, mail, search work.<br>
> <br>
> Transparent proxying is not used.<br>
> Viewing the proxy server logs did not add any understanding, all<br>
> requests are processed correctly and no errors or prohibitions are<br>
> observed. There are no other problems with the unavailability of any<br>
> sites.<br>
> <br>
> When connecting directly (bypassing the proxy server), all Google<br>
> services work completely correctly.<br>
> The platform on which the problem was suddenly discovered:<br>
> FreeBSD 13.2-RELEASE-p9<br>
> Squid 6.6<br>
> <br>
> A new separate server was deployed for objectivity and finding the<br>
> cause, but the problem was also reproduced there, its platform.<br>
> FreeBSD 13.4-RELEASE-p2<br>
> Squid 6.10<br>
> <br>
> I tried using the default configuration file (recommended minimum<br>
> configuration) to eliminate the problem in my working squid.conf,<br>
> but the problem remained<br>
> <br>
> I repeat, the problem reproduced suddenly, no changes were made to<br>
> the proxy server configuration on our side, no problems with Google<br>
> have arisen for many years. What should I pay attention to in the<br>
> Squid configuration? Any idea<br>
> <br>
> <br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>