Hello, Alex, Thanks for your comments.
> if you want more definitive answers, please share a > compressed ALL,9 log while reproducing the problem with that curl > transaction: A link to the uploaded ALL,9 log is: https://drive.google.com/file/d/1kC8oV8WAelsBYoZDoqnNsnyd7cfYOoDi/view?usp=sharing >> I think we could ignore these warnings as squid works perfectly > I do not think we have enough information to reach that "works > perfectly" conclusion. At the very least, you should test with a domain > that should match domdst_SIProxy rather than one that should not match > (and does not match, but for the wrong reason). This is a production system and it works as expected: for domains from the domdst_SIProxy ACL it uses correct tcp_outgoing_address: 10.72.235.184 > If you do not want to know what is actually going on (e.g., whether > there is a Squid bug or misconfiguration here), then you can use a "has" > ACL to protect your domdst_SIProxy ACL in tcp_outgoing_address context > from request-free evaluations. Here is an untested sketch: > > acl hasRequest has request > > # If Squid has no request access (possibly due to Squid bugs), > # then do not use 10.72.235.184, even if domdst_SIProxy would > # have matched if Squid had access to the request. > tcp_outgoing_address 10.72.235.184 hasRequest domdst_SIProxy Thank you, Alex, I will try this workaround after you have time to take a look at ALL,9 log. Kind regards, Ankor. чт, 22 июн. 2023 г. в 20:11, Alex Rousskov <rouss...@measurement-factory.com >: > On 6/22/23 04:59, Andrey K wrote: > > > I reproduced the issue in the test environment. > > I configured my squid with the debug_options: ALL,1 28,9 > > and ran the test curl from the same proxy host: > > curl -m 4 -k --tlsv1.2 --proxy-user 'user:pass' -s -o /dev/null -w > > "%{http_code}" --proxy localhost:3131 https://archive.org > > <https://archive.org> > > > > The client got the 200-response and it works fine. > > > > In the access.log the corresponding records are: > > 2023-06-22 10:59:58| 747 127.0.0.1 NONE_NONE/200/- 0 CONNECT > > archive.org:443 <http://archive.org:443> - HIER_DIRECT/archive.org > > <http://archive.org> - - - - > > 2023-06-22 10:59:58| 201 127.0.0.1 TCP_MISS/200/200 3833 GET > > https://archive.org/ <https://archive.org/> - HIER_DIRECT/archive.org > > <http://archive.org> text/html - - - > > > > The cache.log is available at the link: > > > https://drive.google.com/file/d/12xQch5nHAzijAh4PxZV4mZzjviYX7l7B/view?usp=sharing > > > There are three warnings there: > > grep WARN /tmp/acl.log > > 2023/06/22 10:59:57.875 kid6| WARNING: domdst_SIProxy ACL is used in > > context without an HTTP request. Assuming mismatch. > > 2023/06/22 10:59:57.884 kid6| WARNING: domdst_SIProxy ACL is used in > > context without an HTTP request. Assuming mismatch. > > 2023/06/22 10:59:58.536 kid6| WARNING: domdst_SIProxy ACL is used in > > context without an HTTP request. Assuming mismatch. > > The shared log is not detailed enough for me to pinpoint the problem, > but there are several places in Squid code where tcp_outgoing_address is > used without a request. Some of those places look like Squid bugs to me. > Some look legitimate. Again, I cannot tell whether your Squid is hitting > one of those places; if you want more definitive answers, please share a > compressed ALL,9 log while reproducing the problem with that curl > transaction: > > > https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction > > > The domdst_SIProxy ACL is used only to change the outgoing address for > > specific domains > > > The test URL https://archive.org is not in the domdst_SIProxy list. > > That fact does not matter -- the warnings are printed (and the directive > is ignored) _before_ Squid checks the configured/listed values. > > > > I think we could ignore these warnings as squid works perfectly > > I do not think we have enough information to reach that "works > perfectly" conclusion. At the very least, you should test with a domain > that should match domdst_SIProxy rather than one that should not match > (and does not match, but for the wrong reason). > > > > maybe there is a workaround to suppress logs flooding? > > If you do not want to know what is actually going on (e.g., whether > there is a Squid bug or misconfiguration here), then you can use a "has" > ACL to protect your domdst_SIProxy ACL in tcp_outgoing_address context > from request-free evaluations. Here is an untested sketch: > > acl hasRequest has request > > # If Squid has no request access (possibly due to Squid bugs), > # then do not use 10.72.235.184, even if domdst_SIProxy would > # have matched if Squid had access to the request. > tcp_outgoing_address 10.72.235.184 hasRequest domdst_SIProxy > > > Otherwise, consider sharing an ALL,9 log as discussed above. > > > HTH, > > Alex. > > > > пн, 12 июн. 2023 г. в 10:54, <ngtech1...@gmail.com > > <mailto:ngtech1...@gmail.com>>: > > > > Hey Ankor, > > > > There is some missing context so I would be able to reproduce this > > issue. > > Is this some kind of CONNECT request? > > > > If you can describe in more technical details the setup and what > > client are you using, > > Maybe couple sanitized log lines it would help to understand better > > the scenario. > > > > Eliezer > > > > From: squid-users <squid-users-boun...@lists.squid-cache.org > > <mailto:squid-users-boun...@lists.squid-cache.org>> On Behalf Of > > Andrey K > > Sent: Friday, June 9, 2023 10:03 > > To: Squid Users <squid-users@lists.squid-cache.org > > <mailto:squid-users@lists.squid-cache.org>>; Amos Jeffries > > <squ...@treenet.co.nz <mailto:squ...@treenet.co.nz>> > > Subject: [squid-users] Using tcp_outgoing_address with ACL > > > > Hello, > > > > We use the tcp_outgoing_address feature to access some hosts using a > > dedicated source IP address. > > > > acl domdst_SIProxy dstdomain > > "/data/squid.user/etc/squid/categories/domdst_SIProxy" > > tcp_outgoing_address 10.72.235.129 domdst_SIProxy > > > > It works fine, but logs are flooded with warnings like this: > > 2023/06/09 08:30:07 kid2| WARNING: domdst_SIProxy ACL is used in > > context without an HTTP request. Assuming mismatch. > > > > I found a similar case: > > > http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html > < > http://lists.squid-cache.org/pipermail/squid-users/2015-January/001629.html> > where Amos suggested using a patch as a solution. > > We have Squid Version 5.5. Is there a similar patch for our version, > > or can we just ignore these messages? > > > > Kind regards, > > Ankor. > > > > _______________________________________________ > > squid-users mailing list > > squid-users@lists.squid-cache.org > > <mailto:squid-users@lists.squid-cache.org> > > http://lists.squid-cache.org/listinfo/squid-users > > <http://lists.squid-cache.org/listinfo/squid-users> > > > > > > _______________________________________________ > > squid-users mailing list > > squid-users@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
