Hey, thank you for your response. >> The logs show that clients did issue a CONNECT, however the connections are stuck (and eventually timeout) and netstat is showing exactly 10 connections in SYN_SENT state towards npm registry. I am kinda puzzled, where this number comes from. > > This sounds a bit like other situations where the sslcrtd_program helper has hung and stopped generating certificates. I've checked that and it seems this part is working just fine. > >> Big thank you in advance, br, Jernej >> The "relevant" parts of my configurations are: >> acl intermediate_fetching transaction_initiator certificate-fetching >> http_access allow intermediate_fetching > > This is not all of the required http_access rules. Please list them all. You can check the whole configuration file here: https://pastebin.com/h7ryfArx > >> http_port 80 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/certs/squid-self-signed.crt tls-key=/etc/squid/certs/squid-self-signed.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/certs/squid-self-signed_dhparam.pem disable-pmtu-discovery=transparent >> sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/spool/squid/ssl_db -M 20MB >> sslcrtd_children 8 >> ssl_bump server-first all > > > This "server-first" action is outdated. Please upgrade. The modern equivalent would be: > > acl step1 at_step SslBump1 > ssl_bump peek step1 > ssl_bump bump cachedSites > ssl_bump splice all Updated it to your recommendation. > >> sslproxy_cert_error deny all > > This may be hiding symptoms you need to figure the problem out. It is best to start with everything allowed and only deny the specific errors that are not relevant to the client(s). I've tried to comment it out but there was no difference. >> # dns >> positive_dns_ttl 31 seconds >> negative_dns_ttl 30 seconds > > These also may be the source of problems. They prevent Squid from obeying short-TTL on DNS responses typically used by repositories to load balance large amounts of traffic and/or server failure recovery. Removed. I've ran some additional test and found out that one of the servers (which is resolved from yarnpkg.com) is not accessible and it seeems that that one is causing all the others to halt. Once the connect_timeout period is over, new batch of requests is processed without a problem. Is there a way to disable this behaviour? (or maybe it is actually yarn's behaviour that stops requesting if registry is not available?) Thank you in advance, br, Jernej _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
