操作教程2026年7月3日

从 Squid 到 SOCKS5：Linux 代理环境优化指南

Q: How can you enhance security while configuring a proxy server?

配置代理服务器时，应先避免开放代理：用防火墙或云安全组限制来源 IP，并在 Squid 中配置 ACL、认证和 http_access deny all。同时关闭不必要端口，定期更新系统与代理软件，保护日志和代理凭据。生产环境建议再加入 Fail2ban、速率限制、异常请求告警和定期权限审计。

Q: What tools can be used to monitor and maintain a proxy server?

基础工具包括 systemctl、journalctl、tail、ss、lsof、htop、iotop、tcpdump 和 logrotate。生产环境建议使用 Prometheus + Grafana、Node Exporter、Squid Exporter 或集中式日志平台监控 CPU、内存、连接数、延迟、错误率和缓存命中率。安全维护可结合 Fail2ban、防火墙日志和系统审计日志排查异常访问。

易代理数据方案团队·公开网络数据采集研究·10 分钟阅读

Guide to Setting Up a Proxy Server on Linux

TL;DR: 在 Linux 上搭建代理服务器，建议先选协议与软件：HTTP(S) 场景优先 Squid，通用 TCP 流量可用 SOCKS5；上线前必须配置 ACL/认证、防火墙、日志、监控和更新机制。若需要住宅出口、本地化测试或合规公开网页数据采集，可把自建 Linux 代理作为管理层，再接入 EProxies 的 HTTP(S)/SOCKS5 住宅代理网络：72M+ 住宅 IP、覆盖 195+ 国家、98.2% uptime，价格从 $0.25/GB 起。

Linux 代理服务器适合解决什么问题？

Linux 代理服务器本质上是一个可控的网络中间层：客户端先把请求发给代理，再由代理访问目标服务。常见用途包括统一出口、缓存静态资源、限制访问范围、记录审计日志、调试 API、做本地化页面测试，以及在合规前提下采集公开网页数据。

典型正向代理链路如下：

Client / Browser / Script
        ↓
Linux Proxy Server（如 Squid:3128）
        ↓
Internet / Upstream Proxy / Target Site

如果你的目标只是内网出口管理，自建 Squid 通常足够；如果需要不同国家、城市或 ASN 的住宅网络环境，可以把 Linux 代理接入 EProxies 上游。更多类型对比可参考：代理服务器类型概览。

选择代理类型：HTTP(S)、SOCKS5、正向代理与反向代理

正向代理 vs 反向代理

正向代理：站在客户端一侧，常用于员工出口、脚本请求、缓存和访问控制。Squid 是 Linux 上常见选择，默认端口通常是 3128。
反向代理：站在服务器一侧，常用于把外部请求转发到后端服务，适合负载均衡、TLS 终止和隐藏后端拓扑，常见软件包括 Nginx、HAProxy、Apache。

HTTP(S) vs SOCKS5

HTTP(S) 代理：适合网页请求、API、缓存和基于 URL/域名的 ACL 策略。
SOCKS5 代理：协议更通用，适合更多 TCP 应用，但通常不负责 HTTP 级缓存。

EProxies 同时支持 HTTP(S)/SOCKS5，适合需要住宅 IP、本地化验证、广告检查、价格监测等场景。使用前仍应确认目标网站条款、robots 规则和适用法律，不要把代理用于未授权访问或高压请求。

上线前准备清单

1. 明确用途和边界

先确认代理服务器的角色：内网出口、缓存、开发调试、上游代理网关，还是合规公开数据采集。不同用途决定端口开放范围、日志保留周期、认证方式和是否需要住宅代理出口。

2. 准备系统与网络

建议使用 Ubuntu LTS、Debian、CentOS Stream 或 RHEL 系发行版，并先完成系统更新。上线前检查：

防火墙或云安全组是否只放行可信来源；
是否需要绑定内网 IP，而不是 0.0.0.0；
SELinux/AppArmor 是否影响服务启动；
日志目录和缓存目录是否有足够空间；
是否规划了监控、告警和日志轮转。

3. 规划认证方式

不要部署开放代理。至少选择一种访问控制方式：

只允许固定内网网段；
用户名密码认证；
IP 白名单；
上游代理凭据使用环境变量或密钥管理工具保存。

如果接入 EProxies，可使用用户名密码或 IP 白名单鉴权，并按任务选择轮换会话或粘性会话。

在 Ubuntu 和 CentOS 上安装 Squid

1. 安装 Squid

# Ubuntu / Debian
sudo apt update
sudo apt install squid -y

# CentOS / RHEL
sudo yum install squid -y   # CentOS 7
sudo dnf install squid -y   # CentOS 8+/RHEL 8+

2. 启动并设置开机自启

sudo systemctl enable squid
sudo systemctl start squid
sudo systemctl status squid

3. 配置最小可用 ACL

编辑配置文件：

sudo nano /etc/squid/squid.conf

示例：只允许内网 192.168.1.0/24 使用代理。

http_port 3128

acl localnet src 192.168.1.0/24
http_access allow localnet
http_access deny all

检查语法并重载：

sudo squid -k parse
sudo systemctl reload squid

4. 放行端口

# Ubuntu UFW
sudo ufw allow from 192.168.1.0/24 to any port 3128 proto tcp

# CentOS / RHEL firewalld
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="3128" protocol="tcp" accept'
sudo firewall-cmd --reload

不要直接对公网开放 3128。如果必须跨公网访问，建议配合 VPN、固定源 IP、强认证和速率限制。

5. 客户端测试

curl -x http://SERVER_IP:3128 https://example.com -I

若返回 HTTP 头信息，说明基础链路已通。若连接失败，先检查 systemctl status squid、ss -lntp | grep 3128 和防火墙规则。

可复现的编辑测试记录

为避免只给理论步骤，本文按一台 Ubuntu 22.04、2 vCPU、4GB RAM 的测试机复核了基础流程：安装 Squid、限制 192.168.1.0/24 访问、使用 squid -k parse 校验配置，并用 curl -x 发起 HTTPS HEAD 请求。测试中最常见的问题不是安装失败，而是 ACL 顺序写反、云安全组未放行、或把代理误暴露到公网。结论是：先限制来源，再开放端口，比“先能连通再补安全”更稳妥。

性能优化：先减少无效流量，再增加并发

缓存与连接参数

Squid 适合缓存静态资源，但不应缓存登录态页面、个人数据或敏感接口响应。可从保守参数开始：

cache_mem 256 MB
maximum_object_size 64 MB
refresh_pattern -i \.(jpg|png|css|js)$ 1440 50% 10080
pipeline_prefetch on

上线后观察 TCP_HIT 与 TCP_MISS，再决定是否扩大缓存。缓存命中率低时，盲目增加磁盘空间通常没有意义。

连接与限速

高性能代理不等于无限并发。建议按客户端、目标域名或业务类型分层限速：

acl api_clients src 10.0.1.0/24
acl heavy_sites dstdomain .example.com

delay_pools 1
delay_class 1 2
delay_parameters 1 8000/16000 4000/8000
delay_access 1 allow api_clients heavy_sites

这样可以削峰，减少 429、超时和目标站压力。

上游住宅代理

如果需要住宅出口，可使用：

Client → Linux Squid → EProxies HTTP(S)/SOCKS5 → Target Site

EProxies 提供 72M+ 住宅 IP、195+ 国家覆盖、98.2% uptime，支持轮换与粘性会话，价格从 $0.25/GB 起。轮换会话适合公开页面的大规模区域测试；粘性会话更适合需要会话稳定的登录态验证或持续区域观察。产品详情可查看：EProxies 住宅代理。

安全加固要点

最小暴露

只监听必要地址；
只放行可信源 IP；
禁止开放匿名代理；
不把代理凭据写进代码仓库；
定期更新系统和 Squid。

ACL 与认证

基础 ACL 示例：

acl trusted_net src 10.0.0.0/24
http_access allow trusted_net
http_access deny all

如果需要账号认证，可使用 NCSA/Basic 认证，并定期轮换密码。对于生产环境，建议把认证、来源 IP 限制、防火墙和日志审计同时启用，而不是只依赖一种控制手段。

日志与隐私

Squid 日志可能包含 URL、查询参数、客户端 IP 和认证失败记录。应限制 /var/log/squid/ 访问权限，启用 logrotate，并设定合理保留周期。涉及个人数据或敏感业务时，应先确认内部合规要求。

监控与维护

关键指标

不要只看服务是否在线，还要看质量：

CPU、内存、磁盘 I/O；
并发连接数和带宽；
4xx/5xx、407、超时率；
平均响应时间与峰值延迟；
TCP_HIT / TCP_MISS 缓存命中；
异常来源 IP 与突发请求。

常用命令：

systemctl status squid
journalctl -u squid -f
tail -f /var/log/squid/access.log
tail -f /var/log/squid/cache.log
ss -lntp | grep 3128

常见故障排查

代理连不上

先确认服务状态：

systemctl status squid
ss -lntp | grep 3128

再检查防火墙、云安全组和客户端代理地址。很多连接失败并不是 Squid 问题，而是端口没有对正确来源开放。

配置改完启动失败

运行：

squid -k parse

重点检查 ACL 名称、http_access 顺序、缓存目录权限和配置文件拼写。Squid 的规则顺序很关键，通常应先 allow 明确信任来源，最后 deny all。

407 认证失败

检查客户端格式是否正确：

http://user:password@proxy-host:port

若使用 IP 白名单，确认当前服务器公网出口 IP 是否已加入白名单。接入 EProxies 时，也要确认协议是 HTTP(S) 还是 SOCKS5，以及使用的是轮换会话还是粘性会话。