@@ -1330,3 +1330,199 @@ Thanks.
13301330-Brad
13311331
13321332
1333+ From rousskov at measurement-factory.com Mon Feb 16 00:35:35 2026
1334+ From: rousskov at measurement-factory.com (Alex Rousskov)
1335+ Date: Sun, 15 Feb 2026 19:35:35 -0500
1336+ Subject: [squid-users] dns_nameservers with port?
1337+ In-Reply-To: <3767d125-6cdb-4289-a6aa-2621a86692dc@localities.work>
1338+ References: <3767d125-6cdb-4289-a6aa-2621a86692dc@localities.work>
1339+ Message-ID: <9733d28b-84db-4747-87a8-5d2a82c1be2a@measurement-factory.com>
1340+
1341+ On 2026-02-15 10:42, listy wrote:
1342+
1343+ > Can _dns_nameservers_ take port number?
1344+
1345+ Currently, dns_nameservers rejects name server addresses with port numbers:
1346+
1347+ WARNING: rejecting '127.0.0.1:5353' as a name server, because
1348+ it is not a numeric IP address
1349+
1350+
1351+ > with:
1352+ > _dns_nameservers 10.9.4.7:5350_
1353+ > Squid starts but when I try to use it, Squid logs:
1354+ >
1355+ > ...
1356+ > WARNING: idnsSendQuery: Can't send query, no DNS nameservers known!
1357+ > ??? current master transaction: master56
1358+ > ...
1359+ >
1360+ > What is (not)happening here?
1361+
1362+ After all dns_nameservers addresses were rejected (see above), Squid may
1363+ start but will fail to send any DNS queries, logging the above error
1364+ message. I hope that future Squid versions will refuse to start instead
1365+ (i.e. the "rejecting ..." behavior described above will become a fatal
1366+ configuration error).
1367+
1368+
1369+ FWIW, you can use a non-default port number, one for all custom name
1370+ servers, by building Squid sources with NS_DEFAULTPORT macro defined and
1371+ set to the desired port value. IMO, this hack is not an officially
1372+ supported feature and may disappear without warning or diagnostics.
1373+
1374+
1375+ HTH,
1376+
1377+ Alex.
1378+
1379+
1380+
1381+ From squid3 at treenet.co.nz Mon Feb 16 00:43:11 2026
1382+ From: squid3 at treenet.co.nz (Amos Jeffries)
1383+ Date: Mon, 16 Feb 2026 13:43:11 +1300
1384+ Subject: [squid-users] dns_nameservers with port?
1385+ In-Reply-To: <febe8dcb-76d1-40e2-8ecd-e0e3a4bf71c0@localities.work>
1386+ References: <febe8dcb-76d1-40e2-8ecd-e0e3a4bf71c0@localities.work>
1387+ Message-ID: <83bbb290-88dc-4086-af44-4a73dc4542c1@treenet.co.nz>
1388+
1389+ On 16/02/2026 04:05, listy wrote:
1390+ > Hi guys.
1391+ >
1392+ > Can _dns_nameservers_ take port number?
1393+
1394+ Unfortunately, no.
1395+
1396+
1397+ > with:
1398+ > _dns_nameservers 10.9.4.7:5350_
1399+ > Squid starts but when I try to use it, Squid logs:
1400+ >
1401+ > ...
1402+ > WARNING: idnsSendQuery: Can't send query, no DNS nameservers known!
1403+ > ??? current master transaction: master56
1404+ > ...
1405+ >
1406+ > What is (not)happening here?
1407+
1408+
1409+ The Squid dns_* directives exist to manually provide replacements for
1410+ (some) /etc/resolv.conf settings. Per
1411+ <https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html>, the
1412+ "nameserver" syntax only allows an IPv4, IPv6, or hostname - without port.
1413+
1414+
1415+ Cheers
1416+ Amos
1417+
1418+
1419+ From rousskov at measurement-factory.com Mon Feb 16 01:00:15 2026
1420+ From: rousskov at measurement-factory.com (Alex Rousskov)
1421+ Date: Sun, 15 Feb 2026 20:00:15 -0500
1422+ Subject: [squid-users] Performance issue -- serving from cache
1423+ In-Reply-To: <f771f546-f92e-4c74-9dd5-218653b3f701@brad-house.com>
1424+ References: <f771f546-f92e-4c74-9dd5-218653b3f701@brad-house.com>
1425+ Message-ID: <e90a05cb-f144-4049-8e46-b854d670e4e0@measurement-factory.com>
1426+
1427+ On 2026-02-14 14:45, Brad House wrote:
1428+ > I've got a squid deployment where serving from cache can be slower than
1429+ > an uncached download.? I'm seeing speeds of around 50MB/s when serving
1430+ > from cache, which is much slower than anticipated.? Infact, when hitting
1431+ > fast upstream servers, serving of a non-cached asset is faster (even
1432+ > though its still hitting squid to fetch it).
1433+ >
1434+ > I'm thinking there's got to be something wrong with my squid
1435+ > configuration, I'm currently running on Rocky Linux 10 with Squid 6.10-6.
1436+ >
1437+ > The VM I'm using currently has 4 cores, 16G RAM and 100G of usable
1438+ > space.? I used fio to measure disk performance and I got
1439+ >
1440+ > * Random Write: 3629MiB/s (1MB block), 33.2k (4k block) IOPS
1441+ > * Random Read: 8391MiB/s?(1MB block), 43.5k (4k block) IOPS
1442+
1443+
1444+ What speed to you get when Squid serves the object from the memory
1445+ cache? Do not configure a disk cache for this test to make sure that
1446+ Squid is not reading from disk...
1447+
1448+ I cannot help with AUFS cache_dirs, but _if_ AUFS code uses 4KByte I/O
1449+ blocks, then 50MByte/s you are measuring is equivalent to 12K IOPS which
1450+ is arguably not that bad for that long-neglected AUFS code (compared to
1451+ "raw" 44K IOPS performance you measured with fio)!
1452+
1453+ Please note that I am not trying to imply that rock cache_dir with a
1454+ large slot-size setting would work faster than AUFS. And even if
1455+ properly configured rock does work faster than AUFS, I would be really
1456+ surprised if Squid can approach Traffic Server performance! The two
1457+ projects had vastly different focus and resources.
1458+
1459+
1460+ HTH,
1461+
1462+ Alex.
1463+
1464+
1465+ > Adding more cpu cores or ram doesn't appear to impact performance.
1466+ >
1467+ > The underlying infrastructure is made up of hypervisors with dual 100G
1468+ > uplinks, both the client and squid run on the same hypervisor cloud.
1469+ > Network performance is not the issue.
1470+ >
1471+ > As a test, I spun up Apache Traffic Server and get over 800MB/s when
1472+ > serving from cache.
1473+ >
1474+ > We have a large on site build system that spins up runners for GitHub
1475+ > actions, and they're constantly fetching large assets from the internet
1476+ > for each build, hence our desire for a caching proxy.? We'd rather not
1477+ > switch to Apache Traffic Server as that doesn't have SSL bump capability
1478+ > (we haven't yet enabled that capability in squid, however).? Hopefully
1479+ > there's a simple configuration I'm missing.
1480+ >
1481+ > Just for testing I was pulling large image via http that is below my max
1482+ > object size:
1483+ > http://mirrors.edge.kernel.org/ubuntu-releases/20.04.6/ubuntu-20.04.6-live-server-amd64.iso
1484+ >
1485+ > Configuration below:
1486+ >
1487+ > acl public src 0.0.0.0/0
1488+ > acl SSL_ports port 443
1489+ > acl Safe_ports port 80
1490+ > acl Safe_ports port 443
1491+ > http_access deny !Safe_ports
1492+ > http_access deny CONNECT !SSL_ports
1493+ > http_access allow localhost manager
1494+ > http_access deny manager
1495+ > http_access allow public
1496+ > http_access deny to_localhost
1497+ > http_access deny to_linklocal
1498+ > http_access deny all
1499+ > http_port 8080
1500+ > maximum_object_size 2 GB
1501+ > cache_dir aufs /var/spool/squid 325632 16 256
1502+ > cache_mem 1000 MB
1503+ > maximum_object_size_in_memory 102400 KB
1504+ > coredump_dir /var/spool/squid
1505+ > refresh_pattern -i (/cgi-bin/|\?) 0? ? 0%? ? 0
1506+ > refresh_pattern deb$? ?129600 100% 129600
1507+ > refresh_pattern udeb$? ?129600 100% 129600
1508+ > refresh_pattern tar.gz$? 129600 100% 129600
1509+ > refresh_pattern tar.xz$? 129600 100% 129600
1510+ > refresh_pattern tar.bz2$? 129600 100% 129600
1511+ > refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
1512+ > refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
1513+ > refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
1514+ > refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
1515+ > refresh_pattern changelogs.ubuntu.com\/.*? 0? 1% 1
1516+ >
1517+ >
1518+ > Thanks!
1519+ >
1520+ > -Brad
1521+ >
1522+ >
1523+ > _______________________________________________
1524+ > squid-users mailing list
1525+ > squid-users at lists.squid-cache.org
1526+ > https://lists.squid-cache.org/listinfo/squid-users
1527+
1528+
0 commit comments