谷歌nginx怎么优化？配置和性能调优技巧

谷歌nginx配置文件怎么优化

谷歌nginx的优化得从配置文件说起,这玩意儿就像给车做保养，核心参数调对了，跑起来才顺畅，我之前帮朋友优化他公司的nginx服务器，刚接手时配置文件还是默认的，访问量大一点就卡得像蜗牛，后来调整了几个关键参数，效果立竿见影。

worker_processes这个参数得先说，它控制nginx启动的工作进程数，默认可能是1，但现在服务器CPU都是多核的，把它设成和CPU核心数一致，就像给每个工人分配专属工位，效率能提不少，比如我朋友服务器是4核CPU，改成4后，进程间抢资源的情况少了，响应快了近30%。

worker_connections是每个工作进程的最大连接数，默认1024，对流量大的网站来说肯定不够，我当时根据他网站的并发量，结合服务器内存，调到了10000，不过得注意，这数不是越大越好，太大了会占用过多内存，反而拖慢速度，得像给杯子倒水，倒到快满但不溢出来才刚好。

还有keepalive_timeout，这个是长连接超时时间，默认65秒，对静态资源多的网站，设成120秒左右，能减少重复建立连接的开销，我朋友网站图片和CSS特别多，改完后用户浏览页面时，加载后续资源基本不用重新握手，体验明显顺畅了。

谷歌nginx性能参数调优方法

配置文件只是基础,性能参数调优才是让nginx“起飞”的关键，之前帮一家电商客户做优化，他们促销活动时服务器总崩溃，查了半天发现是性能参数没调好，就像跑步没穿对鞋，怎么使劲都跑不快。

worker_rlimit_nofile这个参数很重要，它是每个进程打开的最大文件数，nginx处理请求时会打开很多文件描述符，默认值可能只有1024，很容易达到上限导致报错，我当时把它设成65535，相当于给服务器开了个“超级仓库”，再也没出现过“too many open files”的错误。

CPU亲和性也得调,worker_cpu_affinity参数能让工作进程绑定到指定CPU核心上，比如4核CPU可以写成“0001 0010 0100 1000”，每个进程固定用一个核心，避免进程在不同核心间切换浪费资源，改完后服务器CPU使用率从忽高忽低变得平稳，响应延迟降了20%。

内存方面,client_body_buffer_size和client_header_buffer_size要根据实际请求大小调整，要是用户经常上传大文件，client_body_buffer_size设小了会频繁读写磁盘，拖慢速度，我给电商客户设成10m，上传商品图片时明显快了，之前传一张图要等5秒，现在2秒内搞定。

谷歌nginx缓存策略设置技巧

缓存就像给网站装了个“记忆大脑”，把用户常访问的内容存起来，下次再要就直接拿，不用重新从服务器取，我自己的博客之前加载很慢，首页要等3秒，设置缓存后，第二次打开几乎秒开，体验差太远了。

expires指令是设置浏览器缓存的利器，针对静态资源比如图片、CSS、JS，直接设个过期时间，像图片这种基本不变的，设成30天；CSS和JS如果更新不频繁，设7天，我博客把背景图设成expires 30d，用户第二次访问时，浏览器直接从本地缓存加载，服务器压力小了，加载速度也快了。

服务器端缓存可以用proxy_cache模块，适合缓存反向代理的内容，比如代理API接口返回的数据，设置缓存后，相同请求直接返回缓存结果，不用再去后端服务取，我帮一个资讯网站做优化时，把热门新闻列表接口缓存5分钟，后端服务器负载降了40%，响应时间从200ms降到50ms。

不过缓存也不能乱设,动态内容比如用户个人中心页面就不能缓存，不然用户看到的可能是别人的信息，我之前就踩过坑，给登录后的页面设了缓存，结果用户A登录后，用户B再访问看到的是A的信息，吓得赶紧把动态页面的缓存关了，这事儿现在想起来还后怕。

谷歌nginx安全加固步骤

nginx优化不光要快,还得安全，不然被黑客攻击了，再好的性能也白搭，之前有个客户网站被挂了马，流量全跑光了，查下来就是nginx没做安全加固，就像家里大门没上锁，小偷随便进。

首先要隐藏nginx版本号，默认响应头里会显示“Server: nginx/1.21.0”，黑客可能根据版本号找漏洞，在配置文件里加“server_tokens off;”，这样响应头就只显示“Server: nginx”，减少被攻击的风险，我给那个客户改完后，安全扫描工具就扫不出具体版本了。

然后是限制请求频率，用limit_req_module模块防止DDoS攻击，比如设置“limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;”，意思是每个IP每秒最多10个请求，超过就拒绝，客户网站之前被恶意刷请求，CPU跑到100%，加了这个配置后，攻击流量直接被挡在外面，服务器立马恢复正常。

HTTPS配置也不能少,现在浏览器对HTTP网站会提示不安全，用户体验差还影响SEO，用Let's Encrypt申请免费SSL证书，配置ssl_certificate和ssl_certificate_key，再加上“ssl_protocols TLSv1.2 TLSv1.3;”启用安全的协议，“ssl_ciphers HIGH:!aNULL:!MD5;”选择强加密算法，我帮客户配完HTTPS，网站在谷歌搜索的排名都往前挪了几位。

谷歌nginx负载均衡配置方式

如果网站流量特别大,单台服务器扛不住，就得用负载均衡，把请求分给多台服务器，就像几个人抬重物，每人分担一点，谁都不累，我之前给一个做在线教育的客户配置负载均衡，3台服务器一起干活，再也没出现过高峰期服务器死机的情况。

最常用的是轮询策略，在nginx配置里定义upstream模块：“upstream backend { server 192.168.1.101; server 192.168.1.102; server 192.168.1.103; }”，proxy_pass 到这个upstream，请求就会依次分给三台服务器，这种方式简单，适合服务器性能差不多的情况。

如果服务器性能不一样,可以用权重策略，给性能好的服务器设更高权重，server 192.168.1.101 weight=5; server 192.168.1.102 weight=3; server 192.168.1.103 weight=2;”，权重5的服务器会处理50%的请求，权重3的处理30%，这样能充分利用高性能服务器，客户有台服务器配置特别好，设了权重5后，它扛了一半的流量，其他两台压力小多了。

还有ip_hash策略，根据用户IP地址分配服务器，能保证同一用户始终访问同一台服务器，适合需要会话保持的场景，比如购物车，不过要注意，如果某台服务器挂了，该IP的用户会被分配到其他服务器，之前的会话可能丢失，所以得配合健康检查模块“server ... max_fails=3 fail_timeout=30s;”，服务器挂了就暂时不分配请求。

谷歌nginx与其他服务器对比优势

现在服务器软件不少,像Apache、IIS、Tomcat，但nginx能脱颖而出，肯定有它的过人之处，我之前对比过好几种服务器，最后还是觉得nginx最“懂事”，用起来省心又高效。

轻量级，资源占用低，nginx的代码写得特别精炼，安装包才几兆，运行时内存占用也小，我在2G内存的服务器上跑nginx，启动后内存占用不到50M，而Apache启动就要100多M，同样配置的服务器，nginx能多跑好几个应用，对小成本网站太友好了。

然后是并发处理能力强，nginx用的是异步非阻塞模型，一个工作进程能同时处理成千上万的连接，而Apache的prefork模型每个连接对应一个进程，并发高了就会很卡，之前做过测试，同样10000并发请求，nginx能轻松处理，响应时间稳定在100ms左右，Apache直接就崩了，CPU跑到100%没反应。

功能强大，扩展性好，nginx不光能当Web服务器，还能做反向代理、负载均衡、缓存服务器，甚至邮件代理，它的模块机制也很灵活，官方和第三方提供了各种模块，想加功能直接装模块就行，不用重编译，不像IIS只能在Windows上跑，nginx跨平台，Linux、Windows、macOS都能用，兼容性拉满。

谷歌nginx优化常见问题解决

优化nginx时难免会遇到各种问题,有时候一个小配置错了，服务器就罢工，我踩过的坑能绕地球一圈，现在把常见问题和解决办法分享出来，帮大家少走弯路。

最常见的是启动时报80端口被占用，有次我刚配好nginx，启动时提示“bind() to 0.0.0.0:80 failed (98: Address already in use)”，第一反应就是有别的程序占了80端口，打开命令行，Windows用“netstat -ano | findstr :80”，Linux用“lsof -i :80”，找到占用端口的进程ID，把它杀掉就行，当时是IIS偷偷启动占了端口，关了IIS nginx就启动成功了。

还有缓存不生效的问题，之前设置了expires指令，但浏览器还是每次都从服务器取资源，查了半天才发现是缓存指令写在了server块里，没写在location块，nginx的配置是有作用域的，location块里的配置会覆盖server块，所以得把缓存相关的指令写在具体的location里，location ~* \.(jpg|jpeg|png|gif)$ { expires 30d; }”，这样静态图片的缓存才会生效。

反向代理后获取不到真实IP也是个头疼事，默认情况下，后端服务拿到的IP是nginx服务器的IP，不是用户真实IP，统计数据就不准，解决办法是在nginx配置里加“proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;”，这样后端服务通过X-Real-IP就能拿到用户真实IP了，我给一个博客客户配完后，他们的访问统计终于能看到用户来自哪里了。