基于Nginx的服务器隐藏与安全配置技术问询

1. 仅允许指定子域名访问，IP/非指定域名直接丢弃请求 #

你的现有配置已经通过return 444实现了丢弃请求，但需要补充IPv6的默认监听，避免遗漏：

# HTTP 所有IP/非指定域名请求直接丢弃
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

# HTTPS 所有IP/非指定域名请求直接丢弃
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    # 后续替换为虚拟证书，先保留占位
    ssl_certificate /path/to/dummy.crt;
    ssl_certificate_key /path/to/dummy.key;
    return 444;
}

# 指定子域名的HTTP跳转HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name examplePanel1.example.net;
    return 301 https://$server_name$request_uri;
}

# 指定子域名的HTTPS服务
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name examplePanel1.example.net;
    # 真实证书配置
    ssl_certificate /etc/letsencrypt/live/example.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.net/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.net/chain.pem;
    # 其他SSL配置保留
    ssl_session_cache shared:SSL:10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    # 安全头配置保留
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header Content-Security-Policy "frame-ancestors 'self'";
    add_header X-Frame-Options DENY;
    add_header Referrer-Policy same-origin;
}

关键：确保default_server同时覆盖IPv4和IPv6，指定子域名的server块不要加default_server，保证精准匹配。

2. 用虚拟证书替代默认443区块的真实证书 #

完全可以用自签名的虚拟证书，避免IP扫描泄露真实域名。生成命令如下：

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/ssl/dummy.key -out /etc/nginx/ssl/dummy.crt -subj "/CN=invalid.invalid"

然后修改默认443 server块的证书路径为上述生成的文件即可。攻击者扫描IP时，只会拿到invalid.invalid的自签名证书，无法获取你的真实域名。

3. 真实IP收到图标请求的原因排查 #

这不是Nginx默认配置导致的，大概率是以下情况：

• Cloudflare反向代理未完全生效：检查域名DNS解析是否仅指向Cloudflare的IP，服务器防火墙是否只放行Cloudflare的IP段；
• 测试或内部访问：服务器本身的进程、脚本或内部网络直接访问了真实IP；
• 绕过Cloudflare的访问：攻击者通过某些方式绕过了Cloudflare代理（比如找到你的真实IP后直接访问）。

解决办法：

• 在防火墙层面仅允许Cloudflare IP访问80/443端口；
• 在指定子域名的HTTPS server块中添加验证，仅信任Cloudflare代理的请求：

# 在指定子域名的HTTPS server块中添加
set $real_ip $remote_addr;
if ($http_cf_connecting_ip) {
    set $real_ip $http_cf_connecting_ip;
}
# 仅允许Cloudflare代理的HTTPS请求
if ($http_cf_visitor !~ '{"scheme":"https"}') {
    return 444;
}

4. 隐藏Nginx标识信息 #

两步操作即可实现：

1. 修改主配置文件nginx.conf，添加或修改：

http {
    server_tokens off; # 隐藏响应头中的Nginx版本信息
    # 可选：自定义Server头（部分模块可能不生效）
    add_header Server "Web Server";
}

2. 如果是编译安装的Nginx，编译时添加参数--without-http_server_tokens，彻底禁用标识输出。
   注意：即使隐藏了Server头，部分错误页面可能仍会泄露，可自定义错误页面避免这种情况。

内容的提问来源于stack exchange，提问作者UnSure