3步搞定域名重定向，揭秘Nginx源码里的性能优化狠招 刚写完Nginx配置，域名跳转却卡死？ 别慌，这通常不是语法错，是架构没搭对。 很多人懂301语法，却不懂底层如何调度，导致高并发下CPU飙高，性能优化全白费。 入口定位：请求是如何被拦截的 在Nginx源码中，处理域名重定向的入口并非简单的字符串匹配，而是位于 src/http/ngx_http_core_module.c 中的 ngx_http_core_find_config 函数。这是理解重定向机制的起点。 当你输入一个URL时，Nginx Worker进程不会直接查配置文件，而是通过哈希表查找对应的 server 块。这一步是高性能的关键。 很多初学者误以为Nginx是线性遍历所有server配置，实际上它预计算了主机名哈希。 // 伪代码示意：核心查找逻辑 ngx_http_core_find_config(ngx_http_request_t *r, ngx_http_conf_ctx_t *conf) {// 1. 获取请求头中的 Host 字段ngx_str_t *host = r-headers_in.host-value;// 2. 计算 Host 的哈希值// 使用 ngx_hash_key 算法，这是Nginx自研的快速哈希uint32_t key = ngx_hash_key(host-data, host-len);// 3. 在预构建的哈希表中查找// 注意：这里不是遍历，是O(1)复杂度查找ngx_http_server_conf_t *s = (ngx_http_server_conf_t *) ngx_hash_find(scf-hash, key, host);if (s) {// 4. 匹配成功，绑定该 server 块r-http_config = s;} else {// 5. 匹配失败，尝试默认 server 或返回444/404r-http_config = scf-default_server;} }这段代码揭示了第一个性能优化点：哈希查找替代线性匹配。 如果你的域名配置有100个，线性匹配需要100次比较，而哈希查找只需1次。 在高并发场景下，这微小的差异会放大成巨大的延迟差。 另外，注意 r-headers_in.host。如果请求没有Host头（如HTTP/1.0请求），Nginx会使用 server_name 中第一个域名作为默认匹配项，或者标记为无效请求。这是很多调试时的盲点。 核心片段：301与302的执行差异 重定向的本质是返回一个HTTP状态码和一个Location头。但在Nginx内部，301和302的处理路径有细微差别，这直接影响缓存行为和客户端体验。 核心逻辑位于 ngx_http_special_response_handler 函数中。当配置了 return 301 http://new-domain.com 时，Nginx会进入以下流程： // 源码片段：ngx_http_core_module.c static ngx_int_t ngx_http_core_return_phase(ngx_http_request_t *r, ngx_phase_handler_t *ph) {ngx_http_core_loc_conf_t *clcf;ngx_http_code_pt_t code;ngx_int_t rc;clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);if (clcf-return_code == NGX_OK) {return NGX_DECLINED;}// 关键：设置响应状态码// NGX_HTTP_MOVED_PERMANENTLY 对应 301// NGX_HTTP_FOUND 对应 302r-headers_out.status = clcf-return_code;// 设置 Location 头// 这里会进行变量替换，支持 $host, $uri 等if (clcf-return_body) {// 如果配置了返回体，则写入ngx_http_send_header(r);}// 触发特殊响应处理code = ngx_http_core_find_phase(r, NGX_HTTP_SPECIAL_RESPONSE_PHASE);if (code == NULL) {return NGX_ERROR;}return code(r); }逐行解析：clcf-return_code：这是配置解析阶段存入的位置。如果你写 return 301，这里就是301。 r-headers_out.status：直接赋值状态码。注意，Nginx不会在这里进行重定向URL的拼接，拼接发生在 ngx_http_special_response_handler 中。 code(r)：调用下一阶段处理函数。这是Nginx“事件驱动”模型的体现。它不直接发送响应，而是把控制权交给下一个Phase Handler。这里有一个容易被忽视的性能优化细节：301会被客户端和中间代理缓存，而302通常不会。 在源码层面，Nginx通过 r-headers_out.last_modified 和 ETag 来控制缓存。对于301，Nginx默认会设置 Cache-Control 头（取决于配置），引导浏览器永久缓存。 对于性能优化来说，这意味着：301：首次访问慢，后续访问极快（浏览器直接跳转，甚至不请求服务器）。 302：每次都要请求服务器，服务器每次都要返回302头。如果你的域名迁移是永久性的，务必使用301。这不仅节省带宽，还能减少服务器CPU开销。 设计思想：为什么Nginx不用正则匹配？ 很多初学者喜欢用 if ($host = old.com) { return 301 ...; }。 在Nginx社区和GitHub开源仓库 nginx/nginx 的Issue列表中，频繁出现关于 if 是“邪恶”的讨论。 Nginx的设计哲学是：配置即状态机。 if 指令在Nginx中并不是一个普通的条件判断，而是一个独立的“重写阶段”指令。它在 ngx_http_rewrite_module.c 中实现。 // 源码片段：ngx_http_rewrite_module.c static ngx_int_t ngx_http_rewrite_if_handler(ngx_http_request_t *r) {ngx_http_rewrite_loc_conf_t *rlcf;ngx_http_rewrite_ctx_t *ctx;ngx_str_t *s;ngx_uint_t i;rlcf = ngx_http_get_module_loc_conf(r, ngx_http_rewrite_module);ctx = ngx_http_get_module_ctx(r, ngx_http_rewrite_module);// 遍历所有 if 条件for (i = 0; i rlcf-if_index; i++) {s = rlcf-ifs[i];// 计算条件变量的值// 这里涉及复杂的变量解析引擎if (ngx_http_complex_value(r, s, val) != NGX_OK) {return NGX_ERROR;}// 判断条件是否成立if (val.len == 0) {// 条件不成立，跳过continue;}// 条件成立，执行 if 块内的指令// 注意：这会改变当前的请求上下文return ngx_http_rewrite_handler(r);}return NGX_DECLINED; }设计思想解读：变量解析开销：if 中的变量（如 $host）需要在运行时解析。这比静态哈希查找慢几个数量级。 上下文污染：if 块内的指令可能会修改请求的URI、方法等，导致后续Phase Handler行为不可预测。这就是为什么Nginx官方文档警告“if is evil”。 性能优化建议：尽量使用 server_name 匹配，而不是 if。如果必须用 if，确保条件尽可能简单，避免正则表达式。在GitHub上，搜索 nginx if performance，你会看到大量关于使用 map 指令替代 if 的讨论。map 指令在配置解析阶段就构建好了哈希表，运行时效率远高于 if。 # 性能优化写法：使用 map map $host $redirect_target {default ;old-domain.com http://new-domain.com;*.old-domain.com http://new-domain.com$request_uri; }server {listen 80;server_name old-domain.com *.old-domain.com;# 如果 map 结果不为空，则重定向if ($redirect_target) {return 301 $redirect_target;} }这种写法将匹配逻辑从运行时转移到了配置解析时，是典型的性能优化手段。 手写简化版：从零实现重定向模块 为了深入理解，我们手写一个极简的Nginx模块，实现域名重定向。这将帮助你看懂源码中的核心逻辑。 // ngx_http_redirect_module.c #include ngx_http.hstatic ngx_int_t ngx_http_redirect_handler(ngx_http_request_t *r); static void *ngx_http_redirect_create_loc_conf(ngx_conf_t *cf); static char *ngx_http_redirect_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child);static ngx_command_t ngx_http_redirect_commands[] = {{ ngx_string(redirect),NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,ngx_http_redirect_set_var,NGX_HTTP_LOC_CONF_OFFSET,0,NULL },ngx_null_command };static ngx_http_module_t ngx_http_redirect_module_ctx = {NULL, /* preconfiguration */NULL, /* postconfiguration */NULL, /* create main configuration */NULL, /* init main configuration */NULL, /* create server configuration */NULL, /* merge server configuration */ngx_http_redirect_create_loc_conf, /* create location configuration */ngx_http_redirect_merge_loc_conf /* merge location configuration */ };ngx_module_t ngx_http_redirect_module = {NGX_MODULE_V1,ngx_http_redirect_module_ctx, /* module context */ngx_http_redirect_commands, /* module directives */NGX_HTTP_MODULE, /* module type */NULL, /* init master */NULL, /* init module */NULL, /* init process */NULL, /* init thread */NULL, /* exit thread */NULL, /* exit process */NULL, /* exit master */NGX_MODULE_V2 };static void * ngx_http_redirect_create_loc_conf(ngx_conf_t *cf) {ngx_http_redirect_loc_conf_t *conf;conf = ngx_pcalloc(cf-pool, sizeof(ngx_http_redirect_loc_conf_t));if (conf == NULL) {return NULL;}conf-redirect_target = NGX_CONF_UNSET;return conf; }static char * ngx_http_redirect_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child) {ngx_http_redirect_loc_conf_t *prev = parent;ngx_http_redirect_loc_conf_t *conf = child;ngx_conf_merge_value(conf-redirect_target, prev-redirect_target, 0);return NGX_CONF_OK; }// 核心处理函数 static ngx_int_t ngx_http_redirect_handler(ngx_http_request_t *r) {ngx_http_redirect_loc_conf_t *rlcf;ngx_str_t target;rlcf = ngx_http_get_module_loc_conf(r, ngx_http_redirect_module);if (rlcf-redirect_target == 0) {return NGX_DECLINED;}// 设置状态码r-headers_out.status = NGX_HTTP_MOVED_PERMANENTLY;// 构建 Location 头// 简化处理，实际需处理变量替换target.data = rlcf-target.data;target.len = rlcf-target.len;// 添加 Location 头if (ngx_http_headers_out(r, r-headers_out.location) != NGX_OK) {return NGX_ERROR;}// 发送响应return ngx_http_send_header(r); }逐行注释与思考：NGX_HTTP_MOVED_PERMANENTLY：这是Nginx内部定义的301状态码。 ngx_http_headers_out：这个函数负责将内存中的 headers_out 结构体序列化为HTTP协议头。 ngx_http_send_header：触发实际的网络发送。注意，这里没有发送Body，因为301/302通常不需要Body。 性能优化点：在实际Nginx源码中，Location 头的构建会使用 ngx_http_complex_value 进行变量替换。如果目标URL包含 $uri，则需要进行字符串拼接。这一步涉及内存分配和拷贝，是重定向过程中的性能瓶颈之一。避坑指南：循环重定向：如果 new-domain.com 又重定向回 old-domain.com，会导致浏览器报错 ERR_TOO_MANY_REDIRECTS。在配置前，务必用 curl -v 测试链路。 协议不一致：HTTP重定向到HTTPS时，需确保SSL证书有效，且443端口开放。 URI丢失：重定向时务必带上 $request_uri，否则用户会丢失查询参数。# 正确写法 return 301 https://new-domain.com$request_uri;# 错误写法（丢失参数） return 301 https://new-domain.com;应用场景：从面试到生产环境 域名重定向不仅是配置技巧，更是系统架构的一部分。 场景一：多域名品牌迁移 假设你将 blog.example.com 迁移到 example.com/blog。 直接使用 return 301 会导致所有子路径都丢失。 正确做法是使用 rewrite 规则： server {listen 80;server_name blog.example.com;# 将 /post/123 重定向到 /blog/post/123rewrite ^/post/(.*)$ /blog/post/$1 permanent;# 其他路径同理rewrite ^/(.*)$ /blog/$1 permanent; }场景二：国际化域名重定向 根据用户IP或语言偏好，将 example.com 重定向到 example.cn 或 example.com。 这需要结合 geo 或 map 指令，以及第三方GeoIP库。 场景三：性能优化与CDN结合 在CDN层配置域名重定向，可以卸载源站压力。 大多数CDN（如Cloudflare、阿里云CDN）都支持在边缘节点执行重定向，这样请求永远不会到达源站。 这是最高级别的性能优化。 面试常考点：301和302的区别？301：永久重定向，浏览器缓存，SEO友好。 302：临时重定向，浏览器不缓存，SEO不友好。Nginx中 if 为什么危险？变量解析开销大，上下文污染，难以调试。如何避免循环重定向？使用 curl -v 追踪，确保链路单向。重定向对SEO的影响？301传递权重，302不传递权重。这个知识点你面试被问过吗？留言说说你的经历。