nginx性能不受server块数量直接影响，关键在server_name匹配效率；精确域名匹配（如server_name api.example.com;）采用哈希查找，o(1)复杂度，而通配符和正则触发线性扫描，应慎用。
直接说结论：Nginx 本身不因 server 块数量多而“变慢”，真正影响性能的是 server_name 匹配过程中的字符串比对效率。只要避免低效匹配方式，哪怕上百个虚拟主机，也不会明显拖慢请求分发。
优先用精确域名匹配
这是最高效的方式。Nginx 对 server_name example.com; 这类完全相等的字符串会做哈希查找，时间复杂度接近 O(1)。
- 写法示例：
server_name api.example.com shop.example.com admin.example.com; - 不要把多个域名拼在一行还混入通配符或正则，比如
server_name *.example.com ~^.*\.example\.com$;—— 这会让 Nginx 跳过哈希表，退回到线性扫描 - 一个 server 块里可写多个精确域名，Nginx 会统一建哈希索引，不增加匹配开销
慎用通配符和正则表达式
以星号开头（*.example.com）或结尾（example.*）的通配符，以及正则（~ 或 ~*），都会触发顺序遍历，且无法被哈希加速。
- 通配符只在没有精确匹配时才参与匹配，但一旦启用，整个 server 块就失去哈希资格
- 正则表达式是最后尝试的匹配方式，且每个正则都要逐个执行，开销最大
- 如果必须用泛域名，优先选
*.example.com（前缀通配），它比正则快；能不用就不用
合理组织 server 块结构
Nginx 在解析请求时，先按 IP+端口筛选出候选 server 块，再在其中匹配 server_name。所以提升效率的关键不是删 server 块，而是减少每次匹配的候选数量。
- 给不同业务分配独立监听地址，比如
listen 192.168.1.10:80;和listen 192.168.1.11:80;，物理隔离匹配范围 - 用
default_server明确指定兜底块，避免 Nginx 自动选第一个作为默认，也减少模糊匹配路径 - 把高频访问的域名放在靠前的 server 块里（仅对无精确匹配、需线性扫描的场景有微弱帮助）
验证与优化建议
改完配置后别只 reload，要实测效果：
- 运行
nginx -t确保语法正确，顺便看 Nginx 是否提示 “using regex” 或 “wildcard” 相关警告 - 用
nginx -T | grep "server_name"检查所有 server_name 写法，快速识别潜在低效项 - 压测时关注
nginx -s stats（需启用 stub_status）里的 accept() / handle() 延迟，若延迟突增，再回溯匹配逻辑
