服务器web

一台服务器装上Nginx，服务监听80端口，服务返回一个HTML页面——这就是服务最基础的Web服务。但真正跑起来，服务事情远没这么简单。服务

我见过太多人把“服务器web”理解成“把文件扔进htdocs就能访问”。服务确实，服务Apache时代这套逻辑很直观：目录对应URL，服务文件即资源。服务但现代Web服务的服务核心早已不是“映射文件”，而是服务“处理请求”。请求进来，服务服务器决定谁来响应、服务怎么响应、服务响应什么。服务这个决策链条，才是Web服务器的本质。

请求进来之后发生了什么

浏览器发来一个GET /api/users。Nginx收到后，先看location匹配规则。如果配了proxy_pass，它就把请求转发给后端Node.js或Go进程。后端处理完，返回JSON，Nginx再塞回给浏览器。整个过程里，Nginx不关心/users是什么，它只负责路由和转发。

这跟早期Apache的mod_php模式完全不同。那时候PHP代码直接嵌在HTML里，Apache自己解析执行。现在更常见的是前后端分离，Nginx只做静态资源和反向代理，动态逻辑交给专门的应用服务器。分工明确，各司其职。

我自己的博客就是这么跑的。Nginx扛住所有入口流量，静态文件直接返回，/api/*的请求转给本地3000端口的Node进程。Node挂了，Nginx还能返回502页面，至少不会整个站点无法访问。

配置里的坑比想象中多

写Nginx配置像在走钢丝。一个location的斜杠位置不同，转发结果可能完全不一样。proxy_pass http://backend/和proxy_pass http://backend，后者会把原始URI原样带过去，前者会替换掉匹配的前缀。这种细节，文档里写得清楚，但实际配的时候还是容易翻车。

还有WebSocket。普通HTTP请求走完就断，WebSocket要升级协议。Nginx默认不支持，得手动加Upgrade和Connection头。我第一次配的时候忘了加proxy_http_version 1.1，连接死活建不起来，查了半天才找到原因。

负载均衡也是。upstream里配了三台后端，默认轮询。但如果某台挂了，Nginx不会自动剔除，得配合max_fails和fail_timeout。这些参数不显眼，关键时刻决定服务可不可用。

静态资源不是扔进去就完事

很多人觉得静态文件最简单，放对目录就行。但缓存策略、压缩、跨域，每一项都能让页面加载速度差出几倍。Cache-Control设成no-cache和max-age=31536000，用户体验天差地别。gzip不开，一个1MB的JS文件传完要好几秒。CORS头配错，前端请求直接被浏览器拦掉。

我习惯给带hash的文件名设一年缓存，index.html设no-cache。这样发版时用户拿到的永远是最新入口，而JS/CSS这些带指纹的资源直接从本地缓存读。简单，但有效。

日志是最后的真相

access.log和error.log，出问题时最先看的就是它们。404多了，说明路由配错或资源路径不对。502频繁，后端进程可能崩了或超时。499是客户端主动断开，通常意味着后端响应太慢，用户等不及关了页面。

我见过有人把日志级别调到debug，结果磁盘两天就满了。生产环境用warn或error就够，access.log按天切割，保留30天。这些运维细节不性感，但少了它们，服务器web就是空中楼阁。

说到底，服务器web不是装个软件就完事。它是一套请求处理流水线，每个环节都得想清楚：谁接、谁转、谁处理、谁返回。配好了，用户无感；配不好，处处是坑。