自建代理IP服务器能解决什么，不能解决什么？
自建解决的是出口收敛与访问控制，解决不了出口IP的数量与可持续性。一台云主机通常只带1个公网IP，加钱可以再挂几个弹性IP，但量级停留在个位数到几十个之间，和采集任务需要的出口规模不在一个数量级。
把需求拆开看，判断会清楚很多：
| 需求类型 | 自建适配度 | 原因 |
|---|---|---|
| 团队统一出口、审计留痕 | 高 | 出口IP固定是优点，便于对端加白 |
| 内网服务对外访问管控 | 高 | 正向代理天然是管控点 |
| 协议转换，如HTTP转SOCKS5 | 高 | 一台机器一份配置即可 |
| 单站点低频采集 | 中 | 频率低时单出口够用 |
| 网站采集器多任务并发 | 低 | 出口IP不足，触发访问频率控制 |
| 舆情监测长周期轮询 | 低 | 单IP持续请求容易被限制 |
| 广告监测多地域校验 | 低 | 自建无法覆盖多城市出口 |
自建是一项基础设施技能，不是出口IP的供给方案。把这两件事混为一谈，是多数自建项目三个月后废弃的原因。
动手之前要确认哪些前置条件？
先确认六项前置条件，缺一项都会在后面返工。逐项对照：
| 前置项 | 确认内容 | 常见坑 |
|---|---|---|
| 服务器 | 公网IP、带宽上限、系统版本 | 按量带宽跑满后限速，采集直接超时 |
| 操作系统 | Ubuntu 22.04或Rocky 9等长期支持版 | 老版本仓库里的软件版本过旧 |
| 端口放行 | 云厂商安全组 + 主机防火墙两层 | 只开了安全组，firewalld仍在拦 |
| 协议范围 | 只需HTTP/HTTPS，还是要SOCKS5 | 选型定了才决定装哪套软件 |
| 出口IP数量 | 计划挂几个公网IP | 决定后面是否要做出口轮换 |
| 合规边界 | 业务授权、日志留存、访问对象范围 | 代理对外开放后被他人利用 |
协议这一项值得单独说。HTTP正向代理靠CONNECT方法建立隧道转发HTTPS流量，该方法定义在HTTP语义规范中；SOCKS5则工作在更低层，定义于RFC 1928，能转发TCP与UDP，对协议不做解析。需要转发非HTTP流量时，SOCKS5是必须项。
Squid正向代理的最小可用配置怎么写？
Squid是HTTP正向代理的常规选择，默认监听3128端口。安装到跑通分四步。
第一步，安装并备份原配置：
bash
sudo apt update && sudo apt install -y squid apache2-utils
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak第二步，写一份精简配置。默认配置文件有数千行注释，直接覆盖成最小集更好维护：
http_port 3128
acl SSL_ports port 443
acl Safe_ports port 80 443
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# 请求环境隔离性相关
forwarded_for delete
via off
request_header_access X-Forwarded-For deny all
# 默认拒绝，鉴权在下一节补
http_access deny all
cache deny all
access_log /var/log/squid/access.log squid第三步，校验语法再启动。跳过校验直接重启，是把服务改挂的高频操作：
bash
sudo squid -k parse
sudo systemctl restart squid && sudo systemctl enable squid第四步，确认端口在监听：ss -lntp | grep 3128。
三条与转发行为直接相关的指令需要记住：forwarded_for delete不再追加客户端来源地址，via off不添加Via响应头，request_header_access按头部名逐项控制。三条一起配，请求环境隔离性才完整。
需要SOCKS5协议时该怎么补齐？
SOCKS5要另装一套服务，Squid本身不提供。常规默认端口是1080，两个可选实现各有取舍：
| 实现 | 特点 | 适合 |
|---|---|---|
| 3proxy | 单二进制，配置文件短，HTTP与SOCKS5可同时开 | 想一台机器两种协议都要 |
| Dante | 老牌服务，访问控制规则表达力强 | 规则复杂、需要按网段细分 |
以Dante为例，一份可跑通的配置骨架：
internal: 0.0.0.0 port = 1080
external: eth0
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect disconnect error
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
protocol: tcp udp
log: connect disconnect error
}external必须填真实网卡名，用ip addr确认，写错会导致服务起来但转发不通。账号走系统用户，用useradd -r -s /usr/sbin/nologin建一个不可登录的专用账号即可。
鉴权和访问控制怎么配，才不会变成公开代理？
代理服务器上线后如果不加鉴权，会在小时级别被扫描器发现并占用。两层防护同时上：账号鉴权加IP白名单。
Squid侧启用基础鉴权，机制遵循HTTP Basic认证规范：
bash
sudo htpasswd -c /etc/squid/passwd apiuser
sudo chmod 640 /etc/squid/passwd && sudo chown proxy: /etc/squid/passwd配置文件追加：
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 20
auth_param basic realm proxy
auth_param basic credentialsttl 2 hours
acl authenticated proxy_auth REQUIRED
acl trusted_src src 203.0.113.0/24
http_access allow authenticated trusted_src
http_access deny all注意http_access allow authenticated trusted_src是与关系，两个条件都要满足。把它写成两行allow就变成了或关系，白名单形同虚设。
三条补充措施按需要叠加：
- 端口不暴露公网：代理只监听内网地址，客户端经WireGuard接入，公网面收敛为一个UDP端口
- 失败重试限制：用fail2ban匹配
access.log中的TCP_DENIED记录，超阈值封IP段 - 凭据轮换：
htpasswd密码定期更换，配合credentialsttl控制缓存时长
怎么验证代理服务器真的生效了？
用一条curl就能验证，关键是看返回的出口地址是否等于代理机的公网IP。
bash
# HTTP代理
curl -x http://apiuser:pass@203.0.113.10:3128 https://api.ipify.org
# SOCKS5代理
curl --socks5-hostname apiuser:pass@203.0.113.10:1080 https://api.ipify.org
# 看完整握手过程
curl -v -x http://203.0.113.10:3128 https://example.com -o /dev/null返回异常时，对照下表定位比翻日志快：
| 现象 | 大概率原因 | 处理 |
|---|---|---|
| 407 Proxy Authentication Required | 凭据未带或错误 | 检查URL中的用户名密码 |
| 403 Forbidden | ACL拒绝 | 核对http_access顺序与白名单 |
| 连接超时 | 端口未放行 | 安全组与firewalld两层都查 |
| 返回的是本机IP | 客户端未走代理 | 检查环境变量与no_proxy |
| HTTPS报证书错误 | 中间做了解密 | 正向代理应走CONNECT隧道，不解包 |
--socks5-hostname与--socks5的差别值得留意：前者把域名解析交给代理端完成，后者在本地解析。做多地域校验时，解析位置会直接改变结果。
高并发采集下要调哪些系统参数？
默认内核参数是给通用服务器准备的，并发一上来先撞文件描述符上限。Linux默认单进程nofile常见值是1024，几百个并发连接就会耗尽。
| 参数 | 默认量级 | 调整方向 | 作用 |
|---|---|---|---|
nofile | 1024 | 65535 | 单进程可开连接数 |
net.ipv4.ip_local_port_range | 32768-60999 | 10240-65000 | 本地端口可用范围 |
net.core.somaxconn | 4096 | 65535 | 监听队列长度 |
net.ipv4.tcp_tw_reuse | 0 | 1 | 复用TIME_WAIT连接 |
net.netfilter.nf_conntrack_max | 按内存计算 | 按并发上调 | 连接跟踪表容量 |
写入方式：
bash
echo "* soft nofile 65535" | sudo tee -a /etc/security/limits.conf
echo "* hard nofile 65535" | sudo tee -a /etc/security/limits.conf
sudo sysctl -w net.ipv4.tcp_tw_reuse=1Squid进程的限制要单独给，limits.conf对systemd管理的服务不生效。正确做法是在/etc/systemd/system/squid.service.d/override.conf里写LimitNOFILE=65535，然后systemctl daemon-reload。这一步漏掉，系统参数调了也白调。
多出口IP轮换在自建环境里怎么实现？
在网卡上挂多个公网IP，再让代理按规则选择出口，是自建轮换的标准路径。两种做法：
做法一，Squid原生指令按ACL分流：
acl group_a src 10.0.1.0/24
acl group_b src 10.0.2.0/24
tcp_outgoing_address 203.0.113.11 group_a
tcp_outgoing_address 203.0.113.12 group_b做法二，iptables按概率做SNAT：
bash
sudo iptables -t nat -A POSTROUTING -m statistic \
--mode random --probability 0.5 -j SNAT --to-source 203.0.113.11
sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 203.0.113.12两种做法的边界必须说清楚：
- 弹性公网IP按个计费，几十个IP的月成本已经不低
- 同一云厂商同一可用区的IP，网段往往连续，对端识别起来没有难度
- IP更换要走控制台或API，做不到分钟级批量轮换
- 出口IP的历史使用情况不可知，拿到手就可能已被限制
自建轮换适合的是出口在个位数、需要按业务线分流的场景，比如把舆情监测和广告监测的流量分到不同出口，互不影响。需要成百上千个可轮换出口时，方案本身就不成立。
上线之后要盯哪几个指标？
代理服务器的故障多数是渐进式的，不是突然宕机，所以监控要盯趋势而不是存活。
| 指标 | 采集方式 | 异常信号 | |
|---|---|---|---|
| 服务存活 | squidclient mgr:info | 无响应 | |
| 连接建立耗时 | 定时curl打点 | 分位值持续上升 | |
| TCP_DENIED占比 | 统计access.log | 突增说明凭据或ACL出问题 | |
| 5xx占比 | 统计access.log | 上升说明上游异常 | |
| 带宽使用率 | vnstat或云监控 | 接近上限即将限速 | |
| 文件描述符 | `ls /proc/<pid>/fd | wc -l` | 逼近nofile上限 |
日志切割要在第一天就配好。access.log在高并发下日增可达数GB，磁盘写满会让服务静默失效。logrotate按日切割保留7天是常见起点，具体天数按合规要求定。
什么场景适合自建，什么场景应该直接采购？
判断只看一条：需要的出口IP数量是否超过自建能稳定供给的量级。超过就采购，不超过就自建。
按场景对照：
| 场景 | 建议 | 理由 |
|---|---|---|
| 企业统一出口、审计留痕 | 自建 | 出口固定是需求本身 |
| 内网服务访问外部API | 自建 | 管控点必须在自己手里 |
| 单站点低频数据抓取 | 自建 | 单出口足够 |
| 网站采集器多任务并发 | 采购 | 出口规模自建撑不住 |
| 舆情监测长周期轮询 | 采购 | 单IP持续请求会被限制 |
| 广告监测多地域校验 | 采购 | 需要多城市出口覆盖 |
| 跨境物流信息查询 | 采购 | 需要境外节点 |
还有一种被低估的组合：自建代理作为统一入口做鉴权、限流与日志留痕，出口段对接采购来的IP资源。管控在自己手里，出口规模交给上游，两边的短板互相补上。
搭建这件事的技术含量，其实在决定不搭什么。把一台机器配到能转发只需要半天，判断这台机器该不该承担轮换职责，才是省下后面三个月运维成本的地方。
FAQ
Q：搭建代理IP服务器需要多高配置的机器？
按并发定，不按流量定。纯转发场景下CPU和内存都不是瓶颈，2核4G能支撑数千并发连接。真正的约束是带宽和文件描述符上限。带宽按峰值并发乘以单请求平均体积估算，留30%余量。如果同时开启日志全量记录，磁盘IO和容量要单独规划。
Q：Squid和Nginx做正向代理有什么区别？
Nginx原生只完整支持反向代理，做正向代理需要额外模块才能处理CONNECT方法转发HTTPS。Squid从设计上就是正向代理，鉴权、ACL、出口地址选择都有原生指令。做正向代理选Squid，改造成本更低。
Q：自建的代理服务器为什么用一段时间就不好使了？
大概率是出口IP被目标站点的访问频率控制机制识别了。单个IP持续高频请求同一站点，对端会先降速再限制访问。自建环境出口数量少，轮换空间小，这个过程会来得更快。降低请求频率能缓解，但解决不了根本约束。
采集HTTP和HTTPS站点，两者都可以，HTTP代理的日志和ACL更细。需要转发非HTTP协议，或者希望域名解析在代理端完成时，用SOCKS5。同一台机器上两种协议可以并存，3proxy一份配置就能同时开。
Q：代理服务器的日志需要保留多久？
按业务合规要求定，不按技术需要定。国内网络安全相关法规对网络日志留存有明确的最短期限要求，具体天数以适用条款为准。技术上要做的是配好logrotate、规划好磁盘容量，并确认日志中不包含不该落盘的请求体内容。
Q：多台代理服务器怎么做负载均衡？
前面放一层HAProxy或Nginx的stream模块做四层转发，后端挂多台代理机。健康检查用TCP探活加一条实际的代理请求探测，只探TCP端口会漏掉进程假死的情况。客户端只对接一个入口地址，后端增减不影响调用方。
