nginx本身不支持正向代理，因此无法在其上配置基于ip的正向代理访问控制；正确方案是选用squid、tinyproxy等原生支持正向代理及acl的专用软件，或企业级代理网关。
Nginx 本身不支持正向代理，这是关键前提。官方 Nginx（开源版）只提供反向代理能力，没有 proxy_http_version 以外的正向代理逻辑，也不解析客户端发起的 CONNECT 请求（HTTPS 代理必需），更无法对浏览器直连请求做 IP 级上网行为拦截。
所以，“Nginx 正向代理中配置基于 IP 的访问控制”这一需求，在标准 Nginx 上无法实现——不是配置写不对，而是功能根本不存在。
如果你实际需要的是“让内网用户通过某台服务器上网，并按 IP 控制谁能上、上哪些网站”，正确路径是：
用支持正向代理的专用软件替代 Nginx
-
Squid：成熟、稳定、原生支持正向代理 + ACL（访问控制列表），可基于
$src（源 IP）、域名、URL、时间等精细管控。例如：acl allowed_ips src 192.168.10.100 192.168.10.101 acl blocked_sites dstdomain .qq.com .taobao.com http_access allow allowed_ips !blocked_sites http_access deny all
- 3proxy 或 TinyProxy：轻量级选择，也支持 IP 白名单/黑名单及 URL 过滤。
- 企业级方案：如使用防火墙（FortiGate、Palo Alto）或统一上网网关（如 iEdge、H3C UTM），它们内置认证、IP 绑定、应用识别和日志审计能力，更适合真实上网行为管理。
如果你误把“反向代理”当成了“正向代理”
常见混淆场景：前端用户访问 http://app.example.com，请求经 Nginx 转发到后端服务 —— 这是反向代理。此时 Nginx 完全可以基于 $remote_addr 做 IP 控制，比如：
location / {
allow 192.168.5.0/24;
allow 2001:db8::/32;
deny all;
proxy_pass http://backend;
proxy_set_header X-Real-IP $remote_addr;
}
但这控制的是“谁可以访问你的 Web 应用”，不是“谁可以通过你上网”。
补充说明：为什么不能硬改 Nginx 实现正向代理？
- 即使通过 Lua 模块（如
ngx_http_lua_module）或第三方补丁强行支持CONNECT，也会缺失 SSL/TLS 握手透传、证书验证、HTTP CONNECT 状态机等核心机制； - 无法处理 HTTPS 流量解密与重签（即中间人模式），也就无法做 URL 或内容级过滤；
- 缺少用户会话跟踪、带宽限速、并发连接控制等上网管理必需能力。
本质上，Nginx 是 Web 服务器/反向代理，不是代理网关。强行让它干正向代理的活，就像用螺丝刀当电钻——临时凑合，但不可靠、不安全、难维护。
真正要做上网行为管理，选对工具比调参数重要得多。
