Yuri Voinov wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> # interceptSupport for IP-Layer NAT interception delivering
> #traffic to this Squid port.
> #NP: disables authentication on the port.
>
> Squid tells you what's wrong:
>
> ERROR: N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
# interceptSupport for IP-Layer NAT interception delivering
#traffic to this Squid port.
#NP: disables authentication on the port.
Squid tells you what's wrong:
ERROR: No forward-proxy ports configured.
In add
I am in the process if migrating from 2.7 to 3.4, and have hit a minor
problem -
if I use "http_port 3128 transparent" as I did in 2.7, it works very well,
but I get a slew of errors on start-up:
squid[1735]: ERROR: No forward-proxy ports configured.
squid: Last message 'ERROR: No forward-pr' r
On 04/17/2016 06:59 AM, Yuri Voinov wrote:
> IDK whats happening.
The answer is probably in the ALL,9 log. Since you can reproduce this
problem on an isolated system with a single transaction, you may be able
to analyze that log to pinpoint the failure. If you cannot or will not
perform that analy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
17.04.16 15:16, Amos Jeffries пишет:
> On 17/04/2016 4:55 a.m., Yuri Voinov wrote:
>>
>> So.
>>
>> Still has no ideas?
>>
>
> Only things I assume you probably already looked at:
>
> Maybe churn in the CA certificates. Linux and Windows distros h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
*NIX means UNIX. Solaris is AT&T UNIX. Linux is not UNIX (C) Linus
Torvalds. :) We are not speaking about all possible OS'es. I suggests
the matter in SSL/TLS, not OS or hands or something similar.
The problem is in CF, I think. As a maximum in pe
On 12/04/2016 5:52 p.m., Dan Charlesworth wrote:
> We have an External ACL Type with %ssl::>sni and %URI
>
> We get access log lines that record the %ssl::>sni just fine, but the
> corresponding line sent to our external ACL is missing it.
>
> For example, from the same request;
>
> Log: 12/Apr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've tried any ciphersuites, including SSL default. With no effect. I
don't think so the issue is in cipher's negotiation.
The only strange I found - queries to problematic sites directly from
proxy box (via proxy) with curl/wget works.
Only LAN
On 16/04/2016 6:06 a.m., Alexander Titaev wrote:
> Hi, Squid-users.
>
> before was
> fbsd 9.3 i386, squid-2.7.9_1, samba36-3.6.23
> 1448899275.777 5230 192.168.0.29 TCP_MISS/200 2823 CONNECT rs.mail.ru:443
> IGM\mtiunov DIRECT/94.100.180.76 -
>
> is now
> 10.2 amd64, squid-3.5.16, samba36-3.6.25
On 16/04/2016 5:13 a.m., Renato wrote:
> Hi guys,
>
> I'm not sure if squid is what I need, so I'll try to explain my
> scenario to make it clear what I need:
>
> I have lots of virtual machines, each one running a web service.
> Those virtual machines are not exposed to the internet.
>
> To acc
On 16/04/2016 9:59 a.m., David Touzeau wrote:
> We have the same issue when upgrading to 3.5.16
>
> 3.5.16 -> squid take 100% CPU
> Back to 3.5.13 -> 12% CPU
>
Does the latest 3.5 snapshot perform better? This may be related to the
Vary regression making varant objects all MISS - and thus longer
On 17/04/2016 4:55 a.m., Yuri Voinov wrote:
>
> So.
>
> Still has no ideas?
>
Only things I assume you probably already looked at:
Maybe churn in the CA certificates. Linux and Windows distros have had
CA cert package updates happen in the past few weeks.
The ChaCha cipher you mentioned Cloud
On 17/04/2016 1:53 p.m., Jok Thuau wrote:
> Blocking YouTube (appear to be on your list) is tricky, if the browser is
> chrome:
>
> https://en.m.wikipedia.org/wiki/QUIC
>
> If you click on the 'green lock' and look at the connection you will see it's
> not using https (funnily enough, the ads t
For me it works.
...
The first thing to do is publish the squid.conf with a bug report
and all other related info.
*NIX doesn't mean CentOS since on CentOS this specific issue doesn't
exit.
I assume that if it works on CentOS it will work almost the same for
U
14 matches
Mail list logo
