HTML本身无法禁止IP访问，因静态文件无服务端逻辑，IP过滤必须在服务器层（如Nginx deny指令）、CDN防火墙或网络边界实现。
HTML 本身做不到 IP 地址保护 —— 浏览器里运行的 HTML/JS 拿不到访客真实 IP，也拦不住请求到达服务器，所有“用 HTML 禁 IP”的方案都是假动作，反而会误导你放松真正该做的防护。
为什么 document.location 或 fetch 无法获取或过滤真实 IP
前端 JavaScript 在用户浏览器中执行，它能看到的只是本地网络环境（比如 127.0.0.1 或内网地址），根本接触不到 HTTP 请求头里的 X-Forwarded-For 或原始 REMOTE_ADDR。那些网上流传的“JS 获取 IP 后跳转/弹窗拦截”的代码，要么读的是伪造的 mock 数据，要么依赖已失效的第三方 API（如早期 https://api.ipify.org 返回的只是出口 IP，且无法用于访问控制）。
- 真实 IP 只在服务器接入层可见（Nginx、Apache、CDN、云防火墙）
- 前端能拿到的所谓“IP”基本来自不可靠的第三方服务，响应可能被缓存、劫持或限流
- 即使 JS 成功判断出某个 IP，也无法中断已发出的请求 —— 页面早已加载完成，资源（图片、脚本、API）仍在后台静默加载
Nginx 中正确配置 IP 限制的三个关键点
真正起效的 IP 控制必须落在 Web 服务器配置上。以 Nginx 为例，常见错误是把 deny 写错位置或忽略继承逻辑。
-
deny必须放在server块顶层或location块内，不能写在if里（Nginx 官方明确不推荐） - 必须配合
allow all，否则默认全部拒绝（deny是黑名单模式，不是白名单） - 若使用 CDN（如 Cloudflare），
$remote_addr拿到的是 CDN 节点 IP，需改用$http_x_forwarded_for并校验X-Real-IP头，同时在源站防火墙只放行 CDN 的 IP 段
示例（仅限未走 CDN 的直连场景）：
立即学习“前端免费学习笔记（深入）”；
server {
listen 80;
server_name example.com;
root /var/www/html;
<pre class='brush:php;toolbar:false;'># 正确：全局禁止两个恶意 IP
deny 203.0.113.42;
deny 198.51.100.15;
allow all;
location / {
try_files $uri $uri/ =404;
}}
CDN 层做 IP 过滤比改服务器配置更可靠
如果你的站点已接入 Cloudflare、阿里云 DDoS 高防、腾讯云 CDN 等服务，优先用它们的防火墙规则，而不是登录服务器改配置。
- CDN 规则生效快（秒级）、可回滚、支持地理围栏（如“仅允许中国 IP”）、自动识别爬虫 UA
- 避免因手误导致整站 502（比如 Nginx reload 失败或语法错误）
- 能过滤掉攻击流量再触达源站，降低服务器负载和日志噪音
- 注意：开启后务必在源站防火墙设置白名单，只允许 CDN 提供的 IP 段（如 Cloudflare 的 IP 列表），否则会把合法流量也挡死
前端能做的唯一有效 IP 相关动作：显式告知用户当前连接状态
你不能靠 HTML 拦 IP，但可以诚实告诉用户“我们检测到您的网络环境可能受限”，并引导其切换网络或联系管理员。这属于体验层补救，不是安全层防护。
- 调用后端 API（如
/api/client-ip）返回经服务器确认的真实出口 IP 和归属地，用于展示而非控制 - 若后端返回
{"blocked": true, "reason": "geo-restricted"}，前端才显示友好提示，不执行重定向或弹窗强制退出 - 绝不把敏感逻辑（如权限判断、功能开关）放在前端做 —— 所有
disabled、hidden、display: none都可被开发者工具绕过
真正要藏 IP，得让服务器退到 CDN 后面；真正要拦 IP，得在 Nginx 或云防火墙里写规则；而 HTML 文件本身，只是个被交付的静态产物，它没有权限、也没有能力参与这次防御。
