★ FEATURED ARTICLE 1. 方案拆解为什么是宝塔WordPress雷池WAF1.1 这套组合到底解决什么问题很多第一次接触服务器的人都会经历从“把网站跑起来”到“让网站不被攻击”的过程。前一个目标相对容易装好面板、一键部署、填几个配置就能上线后一个目标才是真正拉开差距的地方。今天这套组合核心就是把建站和维护安全这件事串联成一个完整闭环宝塔面板负责管理服务器上的站点、数据库、证书和端口WordPress负责快速产出内容雷池WAF负责在流量入口做第一道拦截再通过禁止IP访问把所有能进到站点的通道收敛到域名这一个入口上。我见过太多案例网站刚上线两三天后台就被暴力登录扫过服务器日志里塞满各种扫描记录。不是WordPress本身有多脆弱而是服务器暴露在公网上只要给了它一个入口就一定会有人来敲门。雷池WAF的价值就在这里它不需要你懂很深的攻防原理就可以帮你把常见的Web攻击拦在门外。而禁用IP访问则是从访问控制层面再补一刀让攻击者连源站IP这把钥匙都找不到。这套方案适合谁个人博客站长、中小企业品牌官网维护者、刚入门的运维学习者还有那些曾经“图省事”直接用IP访问建站的人。只要对方访问你网站时必须使用域名安全性和可维护性就会立刻上一个大台阶。1.2 为什么必须禁止使用IP访问网站先说SEO层面。搜索引擎对同一内容的判定一直强调地址唯一性。如果同一个网站既可以通过域名打开又可以通过IP打开搜索引擎会认为这是两份内容带来严重的权重分散问题。更麻烦的是别人通过外链引用你的IP地址后后续收录和排名都可能变得混乱。想靠正规流量做起来IP访问就是那颗老鼠屎。再说安全层面。IP地址一旦被扫到攻击者可以直接用IP发起请求绕过WAF的域名防护策略。雷池WAF位于网站入口时通常会根据Host头、域名规则来分发和拦截请求。如果IP能直连源站等于给攻击者留了一条后门前面的WAF做得再严密也挡不住别人从侧门进来。所以禁IP访问不是洁癖而是部署WAF之后必须配套做的一步。最后是运维层面的可管理性。强制域名访问后Nginx或雷池后端可以清楚记录每个请求来自哪个域名日志归属清晰。如果允许IP访问出问题后排查日志时会发现大量来源不明的记录很难区分是正常用户还是异常扫描。域名访问配合解析记录至少你能知道流量是怎么进来的。1.3 部署后的数据流向先说清楚这套架构在正常情况下的请求路径用户浏览器输入域名DNS解析到雷池WAF所在服务器的IP雷池完成检测后再把合法请求转发给后端运行WordPress的服务器后端返回页面后经过雷池把响应送回浏览器。这里的关键点在于用户真正打到的地址是WAF的IP而不是WordPress源站所在服务器的IP。如果你只有一台服务器后期也完全可以把雷池WAF和WordPress部署在同一台机器上。此时这台机器有两个身份对外是WAF入口对内是网站服务源。外部请求先进雷池雷池再把流量转发给本机Nginx监听的其他端口。无论哪种拓扑“先过WAF再进站点”这条原则是不变的。这也是我建议先想清楚架构再动手的原因架构错了后面每一步都在补漏洞。2. 环境准备与宝塔面板安装2.1 服务器和域名要准备到什么程度部署这套组合建议服务器的CPU不低于2核、内存不小于4G。WordPress本身不稀奇但PHP、MySQL、Nginx跑在一起就占掉不少内存再加Docker和雷池WAF资源紧张的话网站一有访问高峰就会卡顿。我自己的经验是内存越小越容易在排查问题时出现“明明代码没改却打不开网站”的假象其实是被OOM杀掉了进程。操作系统方面主流Linux发行版都能装宝塔。CentOS 7虽是老牌选择但如果已经从系统源里找不到维护更新了我更建议在Debian或Ubuntu这类持续更新的系统上安装。宝塔官方对多发行版都有对应安装脚本关键是安装前不要自己预装一堆乱七八糟的Web环境保持系统干净能让后续排查省掉很多不必要的变量。域名是这套方案绕不开的一环建议提前解析好。第一次部署时如果你还没决定用不用WAF可以先把A记录指向服务器IP等WordPress和证书都部署完成再接雷池并切换解析。这么做的好处是WordPress申请SSL证书时验证路径简单不会出现证书验证请求找不到网站的问题。2.2 安装宝塔面板的具体操作登录服务器后先用ssh工具连接到终端。安装宝塔时请一定以官网当天提供的安装脚本为准下面这段命令是历史版本最常见的安装示例版本不同脚本地址可能变化# CentOS系列参考 yum install -y wget wget -O install.sh https://download.bt.cn/install/install_6.0.sh bash install.sh # Ubuntu/Debian系列参考 wget -O install.sh https://download.bt.cn/install/install-ubuntu_6.0.sh bash install.sh安装过程大概几分钟到十几分钟取决于服务器带宽。脚本执行完终端最后几行会输出宝塔面板的访问地址、默认端口、初始账号和密码。这些信息极其重要我强烈建议你顺手复制到一个本地文档保存而不是只截个图放服务器上。因为安装完经常要重启服务器重启后回车记录早就被被淹没了。安装完成后浏览器打开面板地址一般会看到登录页。第一次登录务必修改面板端口和安全入口。默认的8888端口太过显眼很多人扫端口时第一个试的就是它。把面板端口改成一个高位自定义端口并开启面板SSL能有效减少管理入口被扫描到的概率。2.3 Linux系统层面先做一轮基础加固宝塔装好后先别急着建站这时候是给服务器做基础加固的最佳时间。因为系统是全新的还没有被攻击者发现和扫描早一步锁好门比事后处理日志舒服太多。第一件事是修改SSH登录方式。如果服务器商支持密钥登录建议把SSH默认端口改掉并关闭root密码直接登录。我通常会创建一个普通用户用于日常登录需要管理员权限时再用sudo切换。这样可以避免密码暴力破解器整天尝试root账号即使密码被撞出来也无法直接拿到最高权限。第二件事是在宝塔面板的“安全”里检查端口放行规则。默认情况下只需要在公网放行Web服务需要的端口。如果雷池WAF在另一台服务器上后端服务器甚至可以完全不对公网开放80和443只让WAF的IP访问后端端口。这不是洁癖而是把攻击面压缩到最小。系统防火墙类的工具要在宝塔面板里统一管理避免两边规则冲突这是我踩过几次坑后总结出的经验。3. WordPress建站与域名绑定3.1 用宝塔一键部署LNMP环境宝塔面板登录后进入“软件商店”找到Nginx、MySQL、PHP三个核心软件点击安装。版本选择上Nginx用当前稳定版即可MySQL建议5.7或8.0PHP建议7.4或8.x版本。WordPress官方对PHP版本有明确要求太老的PHP版本不仅无法通过安装检查插件兼容性也会越来越差。为什么需要把这三个软件分开理解Nginx负责处理HTTP请求和静态文件PHP负责执行WordPress的代码逻辑MySQL负责存文章、配置和用户数据。三者缺一不可装完后宝塔会把它们做成一套服务管理。安装顺序上我习惯先装Nginx再装MySQL最后装PHP因为有些编译过程依赖前置组件虽然宝塔会自己处理依赖但按顺序来出错率更低。等待软件安装完成时可以顺手去域名解析商后台把记录确认一遍。DNS解析稍有变动都要等生效时间早点处理好可以避免后面卡壳。3.2 创建站点和数据库进入宝塔“网站”菜单点击“添加站点”。这里需要填写要绑定的域名例如example.com和www.example.com再勾选创建数据库和FTP。数据库类型选MySQL账号密码可以自动生成也可以手动指定。站点目录建议使用默认的/www/wwwroot/你的域名目录命名尽量和项目有关别学我用过一堆test1、test2后来自己都分不清哪个站点是哪个。伪静态选项在添加站点页面里就能选到选择WordPress规则。这一步很重要很多人部署完WordPress后点击文章永久链接出现404绝大多数情况就是伪静态没设置或者设置后Nginx没有reload。宝塔在这里帮了大忙它会自动生成适合当前站点的rewrite规则省去手动写Nginx配置的麻烦。数据库创建好后把库名、用户名、密码完整记录下来。后面安装WordPress时会用到少填一个都进不了安装界面。数据库信息我一般会放在站点的部署备注里但绝不同时保存服务器密码至少错开保存位置降低一次泄露全盘暴露的风险。3.3 下载WordPress并完成安装用宝塔建WordPress有两种方式。一种是直接在软件商店里搜WordPress用一键部署功能它会自动下载并解压到当前站点目录另一种是去WordPress官网下载tar包自己上传到服务器。我通常用第二种因为可以顺便验证网站目录的读写权限是否正常。手动方式大致如下wget https://wordpress.org/latest.tar.gz tar -xzf latest.tar.gz mv wordpress/* /www/wwwroot/你的域名/解压完成后需要确保网站目录的文件所有者属于Nginx运行用户。宝塔默认是www用户如果权限不对WordPress后台会反复提示你输入FTP信息或者无法写入主题和插件。这时在宝塔文件管理里把站点目录的属主和属组都改成www权限目录设为755、文件设为644就能解决大多数权限引发的异常。浏览器访问域名就会出现WordPress安装向导。第一步选择语言第二步填写刚才记录的数据库信息、数据库用户名和密码如果宝塔创建数据库时没指定数据库表前缀可以保持默认的wp_。安装过程中不要关浏览器等它生成配置文件并写入数据库后站点标题和后台管理员账号就是你的专属信息了。安装完成后建议立刻登录后台先把固定链接设置成“文章名”格式再回到宝塔站点设置里检查伪静态是否依然匹配。3.4 申请SSL证书并强制HTTPS现在的网站没有HTTPS浏览器会直接提示不安全非常劝退访客。WordPress部署完成后进入宝塔站点设置里的“SSL”选项卡可以申请免费证书。宝塔集成了免费SSL申请流程选择Lets Encrypt域名的验证方式它会自动校验域名解析记录。申请成功后开启“强制HTTPS”宝塔会自动为站点添加HTTP到HTTPS的301跳转。这样用户即使手动输入http开头也会被安全地引到加密连接。之后返回到WordPress后台在“设置-常规”里把站点地址改成https开头避免后台出现混合内容问题。还有一个小细节很多人申请证书时选了www和主域名两个证书绑定后却忘了检查Nginx配置里是否两个域名都生效了。用浏览器分别访问example.com和www.example.com都看到小锁标志才算合格。只要有一个域名没有证书访客就会看到证书警告信任度直接崩盘。4. 雷池WAF接入与双保险4.1 用Docker安装雷池WAF雷池WAF是一款开源的Web应用防火墙部署形式比较轻核心组件跑在Docker容器里。安装前确认服务器上有没有Docker环境如果没装雷池的官方安装脚本一般会自动处理。这里我强烈建议给雷池一台独立于源站的机器尤其你是做生产环境时可以把WAF机器作为唯一对外入口源站机器只接受WAF转发来的请求。如果确实只有一台服务器那也不是不能装只是端口要提前规划好。我的做法是让雷池占用标准的80和443端口作为对外入口把宝塔Nginx的HTTP端口改成8080HTTPS端口改成8443。所有用户请求先落到雷池经它检测完成后再转发给本机的8080或8443端口。这样做虽然单机资源占用会增加但起码做到了“入口经过WAF”这个核心要求。安装命令请以雷池WAF官方文档为准这里演示在线安装脚本的基本形态# 在线安装脚本会自动检测并准备Docker环境 bash (curl -LfsS https://waf.chaitin.com/release/latest/online/install_online.sh)安装过程比较慢需要拉取多个镜像耐心等它跑完就好。脚本结束时终端会输出雷池管理后台的访问地址、端口和默认账号。这一步一定要保存好和管理面板一样后续登录和排查都离不开。4.2 在雷池里添加站点并切换DNS雷池管理后台登录后进入站点管理添加对外站点。这里两个核心信息要填准一是对外域名example.com二是上游服务器地址。如果你的WordPress在另一台服务器上上游服务器就填那台机器的内网IP和实际监听端口如果是同一台机器上的宝塔Nginx上游地址则填127.0.0.1:8080之类。这里我不建议在一开始就把所有域名都加进去先加一个主域名测试完整链路。等确认流量能正常转发再补充www或其他子域名避免一次配置多个域名时出问题都不知道该查哪一个。添加完站点需要把域名解析切到雷池所在的服务器。登录域名服务商后台将example.com和www.example.com的A记录从原来的源站IP改成雷池所在服务器的IP。这一步切换后所有访问域名的流量都会进入雷池。我在切换前习惯先ping一下原服务器IP把旧IP记下来万一WAF配置有问题至少还能快速改回旧解析恢复访问。切换完成后用手机网络访问一次网站确认页面能正常打开。手机网络不受本地DNS缓存影响能更真实反映全球解析结果是否生效。如果网站打不开先别急着怀疑WAF可能是DNS还在生效等待也可能是源站端口没放行按顺序排查比焦虑有用。4.3 测试雷池WAF的拦截效果接入WAF后最简单有效的验证方法是手工构造几条攻击请求。以SQL注入为例可以在浏览器地址栏里访问带明显注入特征的URLhttp://example.com/?id1 AND 11在正常没有WAF的站点上这样的请求大概率会被后端处理并产生数据库报错接入了雷池后请求应被拦截页面看到的是雷池的拦截提示而不是WordPress的报错信息。如果页面依然能打开且出现数据库错误说明WAF规则没有命中要么是接入模式不对要么是域名没匹配到站点。登录雷池后台查看检测日志可以看到每个被拦截请求的详细信息包括攻击类型、命中规则、来源IP等。常见攻击类型包括SQL注入、XSS跨站脚本、路径穿越、恶意文件上传等。我看日志的习惯是每周固定看一次不是所有拦截都需要处理但突然出现的密集拦截往往预示着有人正在扫描你。4.4 源站加固即使WAF被绕过也要扛住雷池WAF确实能挡掉不少攻击但它不是万能保险。源站服务器的加固仍然要做。如果源站是一台独立服务器我建议利用云平台的安全组或系统防火墙只放行来自雷池所在服务器IP的请求到80/8080和443/8443端口其余来源一律拒绝。等于把源站藏起来攻击者即使知道了IP连不上端口也只能干瞪眼。如果是单机部署雷池和宝塔就需要在宝塔安全配置里注意对外只放行80和443给雷池入口后端用的8080和8443可以仅允许本机访问。公网扫不到这些端口IP直连的威胁就少了一大半。很多人的误区是认为装了WAF就可以把防火墙全开恰恰相反防火墙越严WAF才能发挥真正价值。另外雷池管理后台的端口也不要直接暴露公网。能绑定域名加白名单访问就绑定域名不能的话至少把默认管理端口改成不常见的随机高位端口再配合复杂的后台密码和双因素认证。因为后端管理入口一旦被人进去等于整个站点都是别人的了。5. 禁止IP访问强制域名访问的Nginx配置5.1 为什么只在WordPress站点里做限制不够现在大部分Nginx服务器都会配置多个站点每个站点都有自己的server_name。如果你不显式配置默认站点当用户用IP地址访问服务器时Nginx会默认匹配第一个加载的server块。这个“幸运”站点的内容就可能通过IP泄露到公网。这就是单一WordPress站点里做域名限制不够的原因。你需要的是在Nginx层面增加一个“默认拒绝”的server块凡是不能匹配到任何合法域名的请求一律拒绝连接。这样IP访问就会撞到这个默认站点上而不是落到某个具体网站里。此外如果后端Nginx监听了8080和8443端口IP访问这些端口同样要小心。我见过有人把源站Nginx改成8080后忘了给这个监听端口加默认拒绝规则结果IP加端口扫一眼就能看到WordPress的内容。所以禁止IP访问不是只做一个default_server就完了而是只要Nginx在对外暴露端口都应有一套拒绝逻辑。5.2 在宝塔面板中创建默认站点并返回444最省事的做法是在宝塔“网站”菜单里创建一个“默认站点”。宝塔支持把一个站点设置为默认站点也就是没有匹配到域名时自动落到的站点。我们可以利用这个机制把默认站点目录指向一个空白目录让访问者看到403或者直接断开连接。不过我更推荐直接返回Nginx的444状态码。444是Nginx特有的非标准状态码含义是“什么都不返回直接断开连接”。相比返回403444对扫描器更不友好因为扫描器会把这台服务器判断为“没有对应Web服务”从而降低继续深入探测的意愿。宝塔中手动实现的方式是在默认站点的配置文件里把整个server块替换为server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 444; }保存后让Nginx重载配置。再用浏览器访问服务器IP应该什么内容都没有连接被直接中断。这就是我们要的效果。5.3 处理HTTPS访问IP时的证书问题HTTP配置好了还得考虑到有人会直接访问https://服务器IP。如果443端口的default_server里面没有配置证书Nginx会直接找不到合适的配置而报错甚至影响其他正常的HTTPS站点。所以443端口同样需要一个default_server块。443的default_server需要搭配一张证书。这里不推荐使用正规证书绑定IP因为正规证书本来就很难签给纯IP地址而且IP访问本来就该被拒绝。最简单的方案是生成一张自签名证书专门给这个默认站点用mkdir -p /www/server/nginx/cert/default openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /www/server/nginx/cert/default/privkey.pem \ -out /www/server/nginx/cert/default/fullchain.pem \ -subj /CCN/STZJ/OLocal/CNdefault然后修改默认站点的443配置server { listen 443 ssl default_server; listen [::]:443 ssl default_server; server_name _; ssl_certificate /www/server/nginx/cert/default/fullchain.pem; ssl_certificate_key /www/server/nginx/cert/default/privkey.pem; return 444; }这样IP访问HTTPS时握手阶段时会因为证书不受信任而出现警告继续访问后连接被直接切断。证书警告恰恰说明这个地址不是合法站点正好符合预期。5.4 如何验证禁止IP访问是否真的生效配置完成后需要从外部实际验证一下。最简单的方式是让同网络环境下的另一台终端执行curl -I http://你的服务器IP/ curl -I https://你的服务器IP/正常情况下两条命令都不会返回正常的200状态而是一个奇怪的响应或者超时。如果第一条命令反而返回了WordPress的响应头说明default_server没有生效需要检查是否还有别的server块也设置了default_server或者配置文件加载顺序不对。还要验证“带域名访问”是否正常。因为浏览器访问IP时可能会自动携带一些查询参数或者某些扫描工具会伪造Host头。你可以这样测试curl -I http://你的服务器IP/ -H Host: example.com这条请求虽然是打到IP上的但Host头里写着example.comNginx会根据Host头匹配到正常的WordPress站点。这是刻意为之代表规则只限制“没有合法域名的请求”并不会误伤那种使用域名但临时解析到IP的场景。如果你想彻底连伪造域名都不允许那就是另一套基于访问控制列表的更严格策略但对大部分网站来说做到这一步已经足够安全了。5.5 使用CDN或雷池时的额外提醒如果你把域名解析先切到了雷池WAF再由雷池转发到源站那么对外IP访问看到的入口其实是雷池而不是源站Nginx。这时候源站Nginx的default_server规则主要用于防止有人扫描出源站内网IP或源站端口后直接访问。换句话说雷池入口要拒绝IP解析源站Nginx也要拒绝IP解析两层都做了才闭环。如果后续又套了CDNCDN节点会带着自己的IP去回源此时源站Nginx看到的是CDN的IP但请求里的Host头依然是域名所以default_server规则不会误伤CDN回源。唯一要收紧的是源站防火墙只允许CDN节点或雷池所在服务器的IP访问后端端口其他来源全部拒绝。这一步和禁止IP访问配合起来才是真正的双保险。6. 常见问题与排查技巧实录6.1 域名解析到雷池后网站打不开这个问题我遇到很多次原因通常集中在几个地方。第一是DNS缓存还没过期尤其在你刚修改A记录后的半小时内很多本地的解析结果还是旧IP。这时候用手机4G/5G网络访问或者用在线DNS检测工具解析确认公网是否已经生效。第二是雷池里添加的站点还没绑定完整或者源站地址写错了。检查雷池后台的站点配置看上游服务器IP和端口是不是和宝塔Nginx实际监听端口一致。同机部署时最容易犯的错是雷池填了127.0.0.1:80但宝塔Nginx已经改成监听8080那必然转发失败。第三是源站防火墙没有放行对应端口。如果源站用的8080端口只允许本机访问而雷池容器跑在另一个网络命名空间里同样会因为网络隔离而无法访问。遇到这种情况先在本机里执行curl访问一下源站端口再检查容器网络。6.2 WordPress页面出现404或后台无法登录如果网站前台首页能打开但点击文章链接后40499%是伪静态规则没生效。回到宝塔站点设置在伪静态一栏选择WordPress保存后重载Nginx即可。如果你用其他建站配置或自定义了目录还需要确认WordPress的固定链接是否已经重新保存过一次。后台无法登录常见原因则是缓存插件和强制HTTPS组合导致的跳转循环。先强制使用http或https单一入口清理缓存插件生成的缓存文件再登录一次。如果还是不行通过宝塔文件管理检查wp-config.php里的数据库连接信息是否正确很多时候数据库账号密码被改过或者MySQL服务重启后没有起来后台登录就会一直提示无法建立数据库连接。这里提供一个小技巧遇到WordPress问题先把include的调试开关打开。在wp-config.php中加入如下内容define(WP_DEBUG, true); define(WP_DEBUG_LOG, true); define(WP_DEBUG_DISPLAY, false);然后重新请求出错页面再去查看wp-content/debug.log里的报错信息。多数小白在论坛里问的问题其实都写在这一行日志里。6.3 设置了禁止IP访问后自己的服务器管理后台也打不开有位朋友曾问我为什么配置完default_server后宝塔面板登录页也打不开了。这里务必说明宝塔面板有自己的独立端口和独立服务一般不依赖Nginx的80/443站点所以配置default_server不会影响面板登录。如果面板打不开请先确认面板服务是否正常运行再检查面板端口是否被防火墙拦截。但有一种例外就是你手动修改了面板服务的监听端口或者面板绑定了一个域名而该域名又恰好做了和Nginx冲突的配置。排查时建议先从“服务器终端”登录直接用命令行查看宝塔面板状态而不要急着在浏览器里反复刷新。命令行给的信息永远比浏览器报错更直接。另外很多人配置default_server返回444后习惯用curl -I http://ip测试看到“Empty reply from server”会紧张以为服务器挂了。实际上这恰恰说明444生效了。Nginx什么都没回就是故意让请求方空手而归。真正的服务器异常是连接超时或拒绝连接不会是这个结果。6.4 雷池WAF拦截了正常用户怎么办雷池WAF的规则越严格误拦正常请求的概率也会变高。尤其是站点里有在线支付回调、API接口、用户自定义上传功能时某些合法的动态请求可能被识别成攻击。处理方式不是在WAF里一刀切关掉防护而是到检测日志里找到被拦截的具体记录点开看命中了哪一条规则再为这条请求添加白名单或者调整规则模式。我在配置API类站点时会为这类接口单独设置一个域名或URL路径然后在雷池里对这个路径做更细致的策略。比如允许上传接口只接收预期格式的文件其他格式直接拒绝而不是把整个上传接口的WAF规则全部关闭。安全策略永远是“能收窄就收窄”全开全关都是高风险操作。6.5 排障速查表症状可能原因排查动作域名无法访问IP能访问DNS解析未切换或缓存未过期用在线解析工具查看A记录指向域名能访问但页面不是WordPress雷池或Nginx站点绑定了其他域名检查站点配置文件中的server_name访问IP出现空白且连接中断default_server返回444已生效符合预期无需处理访问IP出现WordPress内容没有设置默认站点或default_server未生效按5.2节配置并检查Nginx配置雷池后台能打开但站点报502上游服务器地址或端口配置错误在雷池里确认上游源站地址能否连通WordPress后台提示数据库连接失败MySQL服务异常或账号密码错误检查MySQL服务状态和wp-config.php配置强制HTTPS后后台循环跳转缓存插件或代理层导致循环清理缓存并检查代理层是否透传HTTPS6.6 最后一组实战经验配置Nginx之前永远先备份配置文件和数据库。禁止IP访问这个操作看起来简单但它修改的是default_server如果某个站点的配置写得不规范重载Nginx时可能连带把正常站点一起拖挂。我习惯在改任何站点配置前先执行nginx -t测试一下配置文件语法全部通过后再reload不要直接粗暴重启。另一个容易被忽视的点是改完全部配置后去查看Nginx错误日志。默认路径一般在/www/wwwroot/站点目录/logs或/var/log/nginx/error.log里面会有很多重载失败、证书加载失败、端口冲突的详细记录。日志里写清楚的行号比网上各种猜测靠谱百倍。最后再提一个我自己的体会很多人在公网上搭建完环境后喜欢立刻用IP访问省事或者把源站IP当作“隐藏域名”直接写进收藏夹。这种习惯真的应该改掉。IP一旦被其他人拿到不管你有没有WAF潜在风险都会成倍上升。先把“只能域名访问”这件事做到位再去优化性能和添加功能整个站点的地基才算真正扎实。
阅读完成 · 觉得有帮助？
