很多团队第一次搭 HTTP 代理，都是"能用就行"：装个软件、开个端口、把地址发到群里。结果跑了两周，问题一个接一个——代理被外部扫到乱用、带宽被某个脚本刷满、出问题想查是谁在什么时候访问了什么却完全没有记录。
鉴权、限流、日志这三件事，看起来是"以后再说"的加分项，实际上是代理环境能不能长期稳定跑下去的地基。这篇文章就用最直白的方式，把这三块怎么配、配到什么程度算合格，一步一步讲清楚。
一、先想清楚：你的代理环境到底给谁用
在动手配置之前，先回答三个问题，后面的参数基本就定了：
1. 使用者是谁？只有内部几个服务器用，还是给几十个同事的电脑用？前者用 IP 白名单就够了，后者必须有账号体系。
2. 访问量大概什么量级？是每天几千次请求的小工具，还是采集任务动辄几十万次的并发场景？量级直接决定限流阈值。
3. 出问题谁负责查？如果没有日志，排障只能靠"重启试试"，这句话在代理环境里几乎等于放弃治疗。
把这三件事写下来，再去看鉴权、限流、日志，你会发现要配的东西其实很有限，但每一样都不能少。
二、鉴权：别让代理变成谁都能进的公共通道
代理和普通服务最大的区别是：它一旦被外部扫到，就等于把你的出口免费开放给所有人。所以鉴权不是可选项，是第一天就要配的东西。
常见的三种方式，各有取舍：
| 鉴权方式 | 优点 | 局限 | 适合场景 |
|---|---|---|---|
| 账密认证（Basic） | 配置简单，所有语言和工具都支持 | 密码会随请求头传输，必须走内网或 HTTPS 隧道 | 给同事、给多台服务器共用 |
| IP 白名单 | 免密码，使用体验最省事 | 换机器、换公网出口就要改配置 | 固定的几台服务器、固定办公网 |
| 令牌鉴权 | 可以按人下发、随时吊销、便于统计 | 需要自己维护令牌表 | 多团队共用、需要核算用量 |
实际项目里最稳的做法是两层叠加：内网机器走 IP 白名单，外部或临时接入走账密 / 令牌，并且给每个使用者一个独立身份，不要出现"全公司共用一个账号"的情况——共用账号等于没有日志。
下面是一段最简的鉴权校验逻辑，思路可以直接搬到任何语言里：
import base64
VALID_USERS = {"team_a": "Pa55w0rd_2024"} # 账号 -> 密码
VALID_TOKENS = {"tk_9f2c8a"} # 令牌，可随时从表中删除
def check_auth(headers):
auth = headers.get("Proxy-Authorization", "")
if not auth.startswith("Basic "):
return None
try:
raw = base64.b64decode(auth[6:]).decode()
user, pwd = raw.split(":", 1)
except Exception:
return None
# 账密正确，或者令牌在白名单里，都放行
if VALID_USERS.get(user) == pwd or user in VALID_TOKENS:
return user
return None # 返回 None 时应答 407 Proxy Authentication Required注意一个细节：校验失败不要返回 403，而要返回 407 Proxy Authentication Required，并在响应头带上 Proxy-Authenticate: Basic realm="proxy"，这样浏览器和 curl 才会主动弹出输入框。
三、限流：把带宽和配额关进笼子里
鉴权解决了"谁能进"，限流解决"进多少"。代理被拖垮，十有八九不是被攻击，而是某个脚本写了个死循环，或者有人拿代理跑高并发任务。
限流建议分三道闸，从细到粗逐层收口：
第一道：速率限制。按账号或按 IP 限制每秒请求数，用令牌桶实现最平滑，允许短时突发但不会长期超速。
第二道：并发上限。限制单个账号同时打开的连接数。很多"代理很慢"的投诉，本质是某个人开了几百个并发把连接池占满了。
第三道：日配额。按账号统计每日请求数或流量，超额后返回 429 而不是直接断网，方便业务侧感知和调整。
import time
class TokenBucket:
"""令牌桶：每秒补 rate 个令牌，最多存 burst 个"""
def __init__(self, rate=20, burst=40):
self.rate, self.burst = rate, burst
self.tokens, self.last = burst, time.time()
def allow(self):
now = time.time()
self.tokens = min(self.burst,
self.tokens + (now - self.last) * self.rate)
self.last = now
if self.tokens < 1:
return False # 应返回 429 Too Many Requests
self.tokens -= 1
return True限流参数不建议一开始就定死，参考这几个经验值再按实际压测微调：
| 参数 | 起手建议 | 说明 |
|---|---|---|
| 单账号 QPS | 10～30 | 普通接口调用足够，采集类可单独提额 |
| 单账号并发连接 | 50～100 | 超过这个数基本是脚本没写回收逻辑 |
| 空闲连接超时 | 60 秒 | 及时回收，避免连接数虚高 |
| 超限状态码 | 429 | 便于业务侧做退避重试 |
四、日志：出问题时唯一能救你的东西
代理日志不是"全都记下来"就好，字段设计得好，一行 JSON 就能定位 90% 的问题。
必备字段一共五类：时间与耗时、账号标识、目标域名、状态码、流量大小。有这五项，就能回答"谁在什么时候访问了哪个站点、成功没有、花了多久、用了多少流量"。
import json, time
def access_log(user, target, status, cost_ms, bytes_out):
print(json.dumps({
"ts": time.strftime("%Y-%m-%dT%H:%M:%S"),
"user": user[:2] + "***", # 账号脱敏
"target": target, # 只记域名，不记完整 URL 参数
"status": status,
"cost_ms": cost_ms,
"bytes": bytes_out,
}, ensure_ascii=False))三个容易踩的坑：
一是别记完整 URL。查询参数里可能带手机号、身份证、订单号，代理层是最容易泄露这些信息的地方，只记域名和路径前缀就够用了。
二是写日志别阻塞请求。用异步队列落盘或推到日志服务，同步写文件在高峰期会把代理拖慢。
三是保留周期要定。排障一般看最近 7 天，成本核算看最近 30 天，长期存储建议只留聚合后的统计值，不然磁盘涨得比业务还快。
五、上线前跑一遍这套自测命令
配置完别急着交付，用 curl 把三个关键路径都验一遍，五分钟就能确认环境是否合格：
# 1. 不带账号密码，应返回 407
curl -x http://127.0.0.1:8888 http://www.baidu.com -I
# 2. 带上账号密码，应返回 200
curl -x http://team_a:Pa55w0rd_2024@127.0.0.1:8888 http://www.baidu.com -I
# 3. 连续快速请求，触发限流应看到 429
for i in $(seq 1 60); do
curl -s -o /dev/null -w "%{http_code}\n" \
-x http://team_a:Pa55w0rd_2024@127.0.0.1:8888 http://www.baidu.com
done | sort | uniq -c如果第 1 条返回 200，说明鉴权根本没生效，先别往下走；如果第 3 条全是 200，说明限流阈值设得过高或者压根没挂上；再顺手翻一下日志，确认五类字段都齐全、账号是脱敏的，这一步做完才算真正可以交付。
六、自建太费劲？把鉴权限流日志交给专业服务
如果团队规模不大、又没有专人维护网络设施，自建代理最耗时的其实不是搭起来的那半天，而是后面持续的参数调优、异常排查和节点稳定性维护。
这种情况更适合直接用成品代理服务。天启HTTP 是国内 IP 代理服务商，提供 HTTP、HTTPS、SOCKS5 三种协议接入，认证方式支持账密认证和 IP 白名单，正好对应前面讲的两种主流鉴权思路；同时提供独享IP、隧道代理和 API 提取等方式，隧道代理只要配一个固定入口，出口 IP 由服务端调度，省掉了自己维护 IP 池的工作量。
把鉴权、换 IP、节点稳定性这些交给服务端之后，你这边只需要专注两件事：在业务侧控制好请求节奏，在本地保留自己的调用日志。这样既满足了本文讲的"可管、可控、可查"，又不用养一套代理基础设施。
需要提醒的是，天启HTTP 提供的是国内节点资源，适合访问国内站点、做本地化数据校验这类场景；如果你的业务需要访问境外站点，那它并不适用，选型时要先确认清楚。具体接入方式和认证配置，以其官网文档为准。
常见问题
Q：代理鉴权用账密还是 IP 白名单更好？
内网固定机器用 IP 白名单最省事，多团队、临时接入、需要分账号统计的场景用账密或令牌更合适。两者可以同时开启，按接入来源分别放行。
Q：为什么配了鉴权，浏览器还是不弹输入框？
多半是失败时返回了 403 而不是 407，或者没有带 Proxy-Authenticate 响应头。代理认证有自己的一套状态码，不能和普通网页认证混用。
Q：限流会不会误伤正常业务？
只要按账号维度设阈值、并允许一定突发量，正常业务基本感知不到。建议先用较宽的阈值跑一周，看日志里的真实分布再收紧，比一开始就拍一个数字靠谱得多。
Q：日志里到底能不能记完整 URL？
不建议。查询参数里常有敏感信息，代理层记录完整 URL 会放大泄露风险。记域名、路径前缀、状态码、耗时和流量，已经足够排障和核算成本。
Q：只给几个人用，还有必要限流吗？
有必要。限流防的往往不是恶意，而是脚本 Bug——一个没写重试间隔的循环就能把带宽刷满。设一个宽松的上限，成本几乎为零，收益是深夜不用被叫起来重启服务。
Q：自建代理和用现成代理服务该怎么选？
看有没有人长期维护。有人维护、有特殊定制需求，自建更灵活；没有专人、又想快速上线，直接用天启HTTP 这类支持账密认证和隧道代理的服务，能省掉大部分基础设施工作。
