Tinyproxy 配置参数详解

目标：逐项实测 Tinyproxy 配置文件（tinyproxy.conf）的全部核心参数——监听与访问控制（Port/Listen/Allow）、连接管理（Timeout/MaxClients/Upstream）、认证与头处理（BasicAuth/AddHeader/ViaProxyName/XTinyproxy/Anonymous）、CONNECT 白名单（ConnectPort）、过滤与错误页（Filter/ErrorFile/StatHost）以及反向代理（Reverse*），每个参数按「改值 → 重启 → 验证回显 → 还原」闭环取证，全部命令与回显已在 Ubuntu 22.04.5 LTS（x86_64）实测通过。

一、环境信息

• 操作系统：Ubuntu 22.04.5 LTS（x86_64）
• Tinyproxy：1.11.0-1（apt 安装，见《Ubuntu 22.04 安装 Tinyproxy 指南》，2026-10-22 实测）
• 代理服务器：10.89.65.10（主机名 proxy1.example.local）
• 客户端/上游测试机：10.89.65.11（主机名 node2.example.local，同内网 10.89.65.0/24，其上另跑一个 8889 端口的 tinyproxy 实例做上游链路与抓包靶机）
• 配置文件：/etc/tinyproxy/tinyproxy.conf（Ubuntu 包默认，共 329 行，实测基线生效项如下节）
• 服务管理：systemctl restart tinyproxy（改配置后必须重启才生效）
• 日志：/var/log/tinyproxy/tinyproxy.log（LogLevel Info 基线）

二、前置条件

• 已按《Ubuntu 22.04 安装 Tinyproxy 指南》完成 apt 安装并确认 systemctl is-active tinyproxy 为 active；
• 具备 root 权限编辑 /etc/tinyproxy/tinyproxy.conf；
• 验证客户端可用 curl；涉及时序测量的验证建议在另一台同网段机器上做远程客户端测试。

三、参数查看与修改方式

3.1 查看当前生效参数

配置文件注释与有效行分离，用 grep 过滤掉注释与空行即可得到「实际生效」的参数全集：

grep -vE "^\s*#|^\s*$" /etc/tinyproxy/tinyproxy.conf

实测输出（Ubuntu 22.04 包默认基线）：

User tinyproxy
Group tinyproxy
Port 8888
Timeout 600
DefaultErrorFile "/usr/share/tinyproxy/default.html"
StatFile "/usr/share/tinyproxy/stats.html"
LogFile "/var/log/tinyproxy/tinyproxy.log"
LogLevel Info
PidFile "/run/tinyproxy/tinyproxy.pid"
MaxClients 100
Allow 127.0.0.1
Allow ::1
ViaProxyName "tinyproxy"
ConnectPort 443
ConnectPort 563

3.2 修改参数的标准流程

Tinyproxy 没有独立的「配置检查」命令行参数（tinyproxy -h 仅提供 -d/-c/-h/-v 四项），配置写错会直接导致服务启动失败。因此修改配置务必走「备份 → 修改 → 重启 → 验证 → 必要时回滚」流程：

cp /etc/tinyproxy/tinyproxy.conf /root/tinyproxy.conf.bak
vim /etc/tinyproxy/tinyproxy.conf
systemctl restart tinyproxy
systemctl is-active tinyproxy

实测「配置写错」时的故障现象——把 Timeout 600 改成非法值 abc 后重启：

Job for tinyproxy.service failed because the control process exited with error code.
See "systemctl status tinyproxy.service" and "journalctl -xeu tinyproxy.service" for details.

systemctl is-active tinyproxy

实测输出：

failed

前台直接运行可以立刻看到具体错误行号（排障技巧）：

/usr/bin/tinyproxy -d

实测输出：

ERROR: Syntax error on line 49

改回正确值并重启后服务恢复 active。

💡 说明：配置文件完整参考可查发行版自带手册 man tinyproxy.conf；上游最新参数模板见 GitHub 仓库 etc/tinyproxy.conf（注意 Ubuntu 1.11.0 与上游 1.11.3 的指令集合略有差异，见下文 Filter/BasicAuthRealm 两处实测差异）。

四、参数总览

按功能域归类的全部参数速查（「默认」列为 Ubuntu 22.04 1.11.0 配置文件的实际值；「上游模板」指 GitHub 1.11.3 的 etc/tinyproxy.conf.in）：

💡 说明：Tinyproxy 采用「一主进程 + 多线程」模型，MaxClients 是同时服务的连接数上限；表格中「上游模板」与 Ubuntu 包的差异主要来自版本跨度（1.11.0 → 1.11.3），升级前建议逐条 diff 配置模板。

五、核心参数分类详解

以下每项均按「原值 → 改值 → 重启 → 实测回显 → 还原」执行，回显逐行照抄。

5.1 User / Group：进程运行身份

Ubuntu 包默认 User tinyproxy + Group tinyproxy。主进程以 root 绑定 8888 端口后降权为该用户运行，用 ps 验证实际身份：

ps aux | grep [t]inyproxy | grep -v grep | head -1

实测输出：

tinypro+     464  0.0  0.0 135488  3024 ?        Sl   10:56   0:00 /usr/bin/tinyproxy

（tinypro+ 为 tinyproxy 的截断显示。）日志目录属主必须与该用户一致，否则日志回落 journald（排障实录见安装指南 4.4 节）。源码编译安装时上游模板默认 User nobody + Group nobody，在 Ubuntu 上会因不存在 nobody 组而启动失败（报 Unable to find group "nobody".），需改 Group nogroup。

5.2 Port：监听端口

原值 Port 8888。改为 18128 验证：

sed -i "s/^Port 8888/Port 18128/" /etc/tinyproxy/tinyproxy.conf
systemctl restart tinyproxy

ss -ltn | grep 18128

实测输出：

LISTEN 0      1024         0.0.0.0:18128      0.0.0.0:*
LISTEN 0      1024            [::]:18128         [::]:*

curl -s -x http://127.0.0.1:18128 -o /dev/null -w "%{http_code}\n" http://example.com

实测输出：

200

要点：默认同时监听 IPv4 与 IPv6；端口低于 1024 需以 root 启动；改端口后防火墙与客户端配置要同步调整。验证后还原为 8888。

5.3 Listen：限定监听地址

原值注释（监听全部网卡）。启用 Listen 127.0.0.1 后重启：

ss -ltn | grep 8888

实测输出：

LISTEN 0      1024       127.0.0.1:8888       0.0.0.0:*

本机与远程客户端对比验证：

curl -s -m 5 -x http://127.0.0.1:8888 -o /dev/null -w "local:%{http_code}\n" http://example.com

实测输出（代理服务器本机）：

local:200

curl -s -m 5 -x http://10.89.65.10:8888 -o /dev/null -w "remote:%{http_code}\n" http://example.com

实测输出（客户端 10.89.65.11）：

remote:000

000 表示连接根本建立不起来（拒绝连接）——Listen 限定后远程来源无法触达端口。要点：上游 1.10.0 起支持多行 Listen 同时绑定多个地址；只做本机代理（如配合本机出网程序）时用 Listen 127.0.0.1 最安全。验证后注释还原。

5.4 Allow：客户端来源白名单

基线含 Allow 127.0.0.1、Allow ::1，另按内网需求放行了 Allow 10.89.65.0/24。删除内网放行行并重启后，远程客户端实测：

curl -s -m 5 -x http://10.89.65.10:8888 -o /dev/null -w "%{http_code}\n" http://example.com

实测输出（客户端 10.89.65.11，被拒）：

403

代理端日志同步记录拒绝事件：

CONNECT   Oct 22 11:21:09.805 [6129]: Unauthorized connection from "10.89.65.11".

重新追加 Allow 10.89.65.0/24 并重启，同一客户端再测：

200

要点：只要出现任意 Allow 行，默认策略即「全部拒绝、命中放行」；支持单 IP、CIDR（10.89.65.0/24）与完整掩码（10.0.0.0/255.0.0.0）写法；Allow 行可以重复多行；与之互补的拒绝写法是 Deny（先 Allow 大段再 Deny 例外）。

5.5 Timeout：空闲连接超时

原值 Timeout 600。改为 3 秒验证（在 10.89.65.11 上用 nc -l 443 起一个不响应的裸 TCP 监听，从代理服务器经 CONNECT 隧道连入并保持空闲）：

sed -i "s/^Timeout 600/Timeout 3/" /etc/tinyproxy/tinyproxy.conf
systemctl restart tinyproxy

time curl -s -m 20 -x http://127.0.0.1:8888 --proxytunnel http://10.89.65.11:443/idle -o /dev/null

实测输出（curl 以空回复退出）：

real    0m3.011s
user    0m0.001s
sys     0m0.004s

隧道建立后无数据交互，3.011 秒时被 tinyproxy 掐断（curl 报 52 Empty reply），与 Timeout 3 精确吻合。要点：Timeout 管「空闲不活动」时长，长连接业务（如隧道内长时间挂起的下载工具）要适当调大；600 秒是上游默认。验证后还原 600。

5.6 MaxClients：并发连接上限

原值 MaxClients 100。改为 3 并用 ab 以 10 并发共 20 请求压测（目标为 10.89.65.11 上的临时 HTTP 服务，经代理转发）：

sed -i "s/^MaxClients 100/MaxClients 3/" /etc/tinyproxy/tinyproxy.conf
systemctl restart tinyproxy
ab -n 20 -c 10 -X 127.0.0.1:8888 http://10.89.65.11:8000/ 2>/dev/null | grep -E "Complete requests|Failed requests"

实测输出：

Complete requests:      20
Failed requests:        0

并发超过 MaxClients 的请求没有被拒绝（0 失败），而是排队等待空闲线程——MaxClients 限制的是「同时活跃的连接数」，超出的连接在监听队列里等待，而不是立刻报错。要点：低配机器适当调小防线程爆炸，高并发网关调大（需配合系统 ulimit -n 与 net.core.somaxconn）。验证后还原 100。

5.7 Upstream：上级代理路由

Upstream 让 Tinyproxy 把命中规则的请求转给上级代理，形成代理链。语法 upstream http <ip:port> ["匹配域"]（可省略匹配域表示全部），另有 socks4/socks5 类型与 upstream none "域"（该域直连不走上级）。在 10.89.65.11 上已运行 8889 端口的上游实例（其配置需放行来源 Allow 10.89.65.0/24），代理服务器追加一行并重启：

upstream http 10.89.65.11:8889

curl -s -m 10 -x http://127.0.0.1:8888 -o /dev/null -w "chain:%{http_code}\n" http://example.com

实测输出：

chain:200

链路生效的直接证据在上游机（10.89.65.11）的日志——请求是它转出去的：

Oct 22 11:32:37 node2.example.local tinyproxy[3357]: Established connection to host "example.com" using file descriptor 4.
Oct 22 11:32:38 node2.example.local tinyproxy[3357]: Closed connection between local client (fd:3) and remote client (fd:4)

上游宕机（systemctl stop tinyproxy 于 10.89.65.11）后，客户端侧实测：

curl -s -m 8 -x http://127.0.0.1:8888 -o /tmp/502.html -w "code:%{http_code}\n" http://example.com
grep -oE "<title>[^<]+" /tmp/502.html

实测输出：

code:404
<title>404 Unable to connect to upstream proxy

要点：上游不可达时返回 404（标题 Unable to connect to upstream proxy），区别于目标站点不可达的 500；匹配域写法支持 ".example.com"（含子域）、"10.0.0.0/8"（网段）与 "."（无域名的裸主机名）；最后一条命中的规则生效，因此「先写特例、最后写全量默认」是固定套路。验证后删除该行还原直连。

5.8 BasicAuth / BasicAuthRealm：代理认证

追加认证行（用户名 root、密码 q1w2e3r4，仅作演示）并重启：

BasicAuth root q1w2e3r4

不带凭据访问：

curl -s -m 8 -x http://127.0.0.1:8888 -o /dev/null -w "noauth:%{http_code}\n" -D /tmp/407hdr http://example.com
grep -i proxy-authenticate /tmp/407hdr

实测输出：

noauth:407
Proxy-Authenticate: Basic realm="Tinyproxy"

带凭据访问：

curl -s -m 8 -U root:q1w2e3r4 -x http://127.0.0.1:8888 -o /dev/null -w "auth:%{http_code}\n" http://example.com

实测输出：

auth:200

⚠️ 版本差异实测：上游 1.11.3 模板中的 BasicAuthRealm "Office-Proxy" 指令在 Ubuntu 22.04 的 1.11.0 上无法解析——写入后前台运行直接报 ERROR: Syntax error on line 226 / Unable to parse config file. Not starting.（无论带不带引号），407 响应固定使用代码内置的 realm "Tinyproxy"。需要自定义 realm 请使用 1.11.1 及以上版本。多行 BasicAuth 可配置多个账号。

验证后删除该行还原无认证状态（无凭据请求恢复 200）。

5.9 AddHeader：追加出站请求头

启用 AddHeader "X-My-Header" "Powered by Tinyproxy" 并重启，在 10.89.65.11 上用 nc -l 9999 抓取代理转发来的原始请求：

GET /addhdr HTTP/1.0
Host: 10.89.65.11:9999
Connection: close
Via: 1.1 tinyproxy (tinyproxy/1.11.0)
User-Agent: curl/7.81.0
Accept: */*
X-My-Header: Powered by Tinyproxy
X-Tinyproxy: 127.0.0.1

X-My-Header 成功注入出站请求。要点：仅对 HTTP 流量生效，HTTPS 隧道内流量对代理不可见因此无法注入；可用于内网溯源标记、灰度标头等场景。验证后注释还原。

5.10 ViaProxyName / DisableViaHeader：Via 头控制

基线 ViaProxyName "tinyproxy"，转发请求自动携带（见 5.9 抓包）：

Via: 1.1 tinyproxy (tinyproxy/1.11.0)

把 ViaProxyName 改为自定义值（如 "gw01"）后，Via 头变成 Via: 1.1 gw01 (tinyproxy/1.11.0)。启用 DisableViaHeader Yes 再抓包：

GET /novia HTTP/1.0
Host: 10.89.65.11:9999
Connection: close
User-Agent: curl/7.81.0
Accept: */*
X-Tinyproxy: 127.0.0.1

Via 头消失（即所谓 stealth 模式）。要点：RFC 2616 要求代理追加 Via，禁用属于破坏兼容性的隐身行为，仅在明确需要隐藏代理存在时使用。验证后还原。

5.11 XTinyproxy：向源站透传客户端 IP

启用 XTinyproxy Yes 后抓包（见 5.9 输出最后一行）：

X-Tinyproxy: 127.0.0.1

值为发起请求的客户端 IP（本例 curl 在代理本机执行所以是 127.0.0.1；远程客户端则显示其真实 IP，如 10.89.65.11）。要点：后端需要识别真实来源时开启（配合 Nginx 的 real_ip 模块等），注意该头可被伪造，后端只应信任来自代理 IP 的请求。验证后注释还原。

5.12 Anonymous：请求头白名单（匿名代理）

启用 Anonymous "Host"（可多行，每行放行一个头）并重启后抓包：

GET /anon HTTP/1.0
Host: 10.89.65.11:9999
Connection: close
Via: 1.1 tinyproxy (tinyproxy/1.11.0)
X-Tinyproxy: 127.0.0.1

与 5.9 对比：User-Agent、Accept 均被剥离，只剩白名单内的 Host（加上代理必需的 Connection 与代理自身的 Via/X-Tinyproxy）。要点：这是「匿名代理」模式——限制浏览器指纹外泄，但过多白名单会导致部分网站异常（缺 Cookie/UA），需按业务最小放行。验证后注释还原。

5.13 ConnectPort：CONNECT 隧道端口白名单

基线 ConnectPort 443 + ConnectPort 563，CONNECT 只能连这两个端口。直接对 9999 端口发起隧道（10.89.65.11 起了 nc 监听）：

curl -s -m 5 -x http://127.0.0.1:8888 --proxytunnel -o /dev/null -w "%{http_code}\n" http://10.89.65.11:9999/

实测输出（被白名单拒绝，隧道无法建立）：

000

追加 ConnectPort 9999 后重试，curl -v 显示隧道建立成功：

> CONNECT 10.89.65.11:9999 HTTP/1.1
< HTTP/1.0 200 Connection established
* Proxy replied 200 to CONNECT request

隧道建立后目标端口无人监听时的回显（上游机 nc 已退出）：

HTTP/1.0 500 Unable to connect

再把某一行改为 ConnectPort 0（全部禁用 CONNECT）实测：

HTTP/1.0 403 Access violation

同时普通 GET 不受影响（plain-get:200）。要点：白名单未命中时 CONNECT 直接被拒；ConnectPort 0 一行即可整体禁用 CONNECT（HTTPS 隧道也随之失效）；对外提供代理时收紧 ConnectPort 是最重要的防滥用手段。验证后还原为 443/563。

5.14 StatHost / StatFile：内置统计页

默认请求主机名 tinyproxy.stats（StatHost 默认值）即返回统计页而非转发：

curl -s -m 8 -x http://127.0.0.1:8888 http://tinyproxy.stats/ | grep "<title>" | head -1

实测输出：

<title>tinyproxy version 1.11.0 run-time statistics</title>

统计页由 StatFile "/usr/share/tinyproxy/stats.html" 模板渲染（模板内 {package}/{version} 占位符由进程替换为实际值）。自定义 StatHost 验证：

StatHost "proxy.stats.local"

curl -s -m 8 -x http://127.0.0.1:8888 http://proxy.stats.local/ | grep "<title>" | head -1

实测输出：

<title>tinyproxy version 1.11.0 run-time statistics</title>

此时默认主机名 tinyproxy.stats 不再命中，请求被当普通转发处理（DNS 解析失败返回 500 页）：

<title>500 Unable to connect</title>

验证后删除 StatHost 行还原。

5.15 ErrorFile / DefaultErrorFile：自定义错误页

先造一个必然 403 的场景（Filter 拦截，见 5.16），再配置自定义 403 页：

ErrorFile 403 "/etc/tinyproxy/403.html"

/etc/tinyproxy/403.html 内容为 <html><body><h1>自定义 403：域名已被代理策略拦截</h1></body></html>。重启后经代理访问被过滤域名：

curl -s -m 8 -x http://127.0.0.1:8888 http://example.com | head -1

实测输出：

<html><body><h1>自定义 403：域名已被代理策略拦截</h1></body></html>

要点：ErrorFile 可为 400/403/408/502/503 等状态码逐个定制，未定制的状态码回落 DefaultErrorFile（默认 default.html）；错误页里可以写中文，直接输出。验证后删除还原。

5.16 Filter 系列：域名/URL 过滤

建过滤文件 /etc/tinyproxy/filter，内容一行 example.com；配置启用 Filter "/etc/tinyproxy/filter"（默认策略放行未命中者）并重启：

curl -s -m 8 -x http://127.0.0.1:8888 -o /dev/null -w "blocked:%{http_code}\n" http://example.com
curl -s -m 8 -x http://127.0.0.1:8888 -o /dev/null -w "allowed:%{http_code}\n" http://example.org

实测输出：

blocked:403
allowed:200

代理端日志：

NOTICE    Oct 22 11:25:51.139 [6416]: Proxying refused on filtered domain "example.com"

再叠加 FilterDefaultDeny Yes（反转默认策略：白名单模式）后实测：

now-allowed-list:200
now-other:403

要点：过滤按域名匹配（FilterURLs On 改为按整条 URL 过滤）；正则类型上 Ubuntu 1.11.0 的指令是 FilterExtended（POSIX 扩展正则），上游 1.11.1+ 换成 FilterType bre/ere/fnmatch（1.11.1 新增 fnmatch），跨版本迁移配置时注意改名；FilterCaseSensitive On 开启大小写敏感。验证后删除 Filter 行与过滤文件还原。

5.17 LogFile / Syslog / LogLevel：日志三件套

三者关系：LogFile 指定文件日志；Syslog On 改走系统日志（二者互斥，同时只能启用一个）；LogLevel 控制详略（Critical/Error/Warning/Notice/Connect/Info，自左向右越来越详细）。

LogLevel 切到 Connect 后发一次请求，日志只留连接级事件：

CONNECT   Oct 22 11:29:03.608 [6530]: Established connection to host "example.com" using file descriptor 4.

（Info 级别下还会有的 Closed connection between local client ... 等 INFO 行被抑制。）切到 Warning 后请求完成日志零新增（文件行数不变），只记录告警以上事件。

Syslog 模式实测：注释 LogFile 行、写入 Syslog On 并重启后，日志进入 journald：

Oct 22 11:29:13 proxy1.example.local tinyproxy[6558]: Established connection to host "example.com" using file descriptor 4.
Oct 22 11:29:15 proxy1.example.local tinyproxy[6558]: Closed connection between local client (fd:3) and remote client (fd:4)

要点：排障期用 Info，稳定期用 Connect 或 Warning 降噪；systemd 托管下不配 LogFile 也不配 Syslog 时输出进 journald（journalctl -u tinyproxy 查看）。验证后还原 LogFile + Info。

5.18 Bind / BindSame：出站源地址绑定

启用 Bind 10.89.65.10 并重启，代理功能正常（多宿主场景下指定出站源 IP）：

curl -s -m 8 -x http://127.0.0.1:8888 -o /dev/null -w "%{http_code}\n" http://example.com

实测输出：

200

BindSame yes 则出站源地址自动等于入站请求到达的那个 IP（一台机器多 IP 对外呈现不同出口时使用）。验证后注释还原。

5.19 ReversePath / ReverseOnly / ReverseMagic / ReverseBaseURL：反向代理

用一个独立配置实例验证（复制主配置后改 Port 18129，并写入）：

ReversePath "/example/" "http://example.com/"
ReverseOnly Yes

后台启动该实例后按路径访问：

curl -s -m 10 http://127.0.0.1:18129/example/ | grep -oE "<title>[^<]+" | head -1

实测输出（example.com 内容经反向路径透出）：

<title>Example Domain

ReverseOnly 生效时普通正向代理被拒绝：

curl -s -m 8 -x http://127.0.0.1:18129 -o /dev/null -w "%{http_code}\n" http://example.org

实测输出：

400

要点：多行 ReversePath 可把多个站点拼接到同一前缀树下；ReverseMagic Yes 用 Cookie 跟踪映射（目标站使用绝对链接时必需）；ReverseBaseURL 用于重写重定向防止跳出代理域。做反向代理时官方强烈建议同时开启 ReverseOnly 关闭正向代理功能。验证后删除实例配置与进程。

六、生产配置模板

面向「内网多客户端共享出网 + 基础防护」的推荐基线（2 vCPU / 2GB 内存 / 千兆内网场景），在 Ubuntu 默认配置基础上调整：

User tinyproxy
Group tinyproxy
Port 8888
Timeout 600
MaxClients 200
Allow 10.89.65.0/24
BasicAuth root q1w2e3r4
ConnectPort 443
ConnectPort 563
ViaProxyName "gw01"
XTinyproxy Yes
LogFile "/var/log/tinyproxy/tinyproxy.log"
LogLevel Connect
PidFile "/run/tinyproxy/tinyproxy.pid"
DefaultErrorFile "/usr/share/tinyproxy/default.html"
StatFile "/usr/share/tinyproxy/stats.html"

逐项说明：

• MaxClients 200：2GB 内存下按每连接约 30KB 常驻估算留足余量，内网 50 人规模够用；
• Allow 10.89.65.0/24：只放行内网网段，公网地址一律拒绝；
• BasicAuth root q1w2e3r4：内网加一层账号门槛，防止被内网失陷主机滥用（演示凭据，生产请改强密码）；
• ConnectPort 443/563：只允许 HTTPS 相关隧道，封堵用代理连非常用端口的滥用；
• ViaProxyName "gw01"：Via 头显示网关名，便于下游识别来源代理；
• XTinyproxy Yes：后端服务可拿到真实客户端 IP；
• LogLevel Connect：记录每次连接但不刷屏，配合 logrotate 轮转。

⚠️ 注意：BasicAuthRealm 在 1.11.0 上不可配置（见 5.8）；若代理暴露面大，优先考虑升级到 1.11.3（含 1.11.2 的 UAF 安全修复）再启用更多特性。

七、常见问题（FAQ）

Q1：改了配置为什么没生效？ 配置只在进程启动时读取，改完必须 systemctl restart tinyproxy；确认 systemctl is-active tinyproxy 为 active 后再测。

Q2：重启失败报 Job failed，如何快速定位错误行？ 执行 systemctl is-active tinyproxy 确认 failed，再前台运行 /usr/bin/tinyproxy -d，输出里的 ERROR: Syntax error on line N 直接给出错误行号（见 3.2 实测）。

Q3：客户端拿到 403 Access denied？ 来源 IP 不在 Allow 白名单。日志会记 Unauthorized connection from "10.89.65.11".，按 5.4 追加对应网段即可。

Q4：想给不同网段走不同出口怎么办？ 用 Upstream 规则组：先写特例（upstream http <A> "10.0.0.0/8"）、最后写全量默认（upstream http <B>），最后一条命中规则生效（见 5.7）。

Q5：加了 BasicAuth 后所有请求都 407？ BasicAuth 一旦出现，所有客户端都要带凭据；curl 用 -U root:q1w2e3r4 传递。若想让部分来源免认证，只能拆实例（不同 Port/Listen + 不同配置文件）。

Q6：HTTPS 网站走代理报错/被拒？ 先看 ConnectPort 白名单是否覆盖 443（改过就还原或补上），再确认客户端用的是 https_proxy/--proxytunnel 形式的 CONNECT 隧道而非普通 GET。

八、参考链接

• 本机手册：man tinyproxy.conf（发行版自带，与 1.11.0 指令集一致）
• 上游最新配置模板（GitHub，1.11.3，查询日期 2026-10-22）：https://github.com/tinyproxy/tinyproxy/blob/1.11.3/etc/tinyproxy.conf.in
• 官方站点：https://tinyproxy.github.io/
• 安装与 systemd 托管实测见《Ubuntu 22.04 安装 Tinyproxy 指南》（本专栏，2026-10-22 实测）
• 介绍、架构与选型对比见《Tinyproxy 介绍与选型指南》（本专栏）