标签：Nginx

共 126 篇相关文章

IT 累计浏览 4

解决访问 https 网站时，后端重定向或获取 URL 变成 http 的问题

在常见的Nginx反向代理后端Java应用的部署架构中，客户端与Nginx之间为HTTPS，但Nginx转发至后端服务器的请求协议为HTTP。这会导致后端应用通过`HttpServletRequest.getRequestURL()`获取到的URL为内网HTTP地址，且`HttpServletResponse.sendRedirect()`生成的重定向地址也为HTTP，无法反映真实的客户端访问协议。解决此问题需结合Nginx配置与后端代码调整。对于URL获取问题，需在Nginx中通过`proxy_set_header Host $host`和`proxy_set_header X-Forwarded-Proto $scheme`向后端传递原始主机名与协议信息。后端Java应用则需通过自定义Servlet过滤器，读取`X-Forwarded-Proto`头并重写请求的`getScheme()`与`getRequestURL()`方法，确保返回正确的HTTPS URL。对于重定向问题，可通过Nginx的`proxy_redirect http:// $scheme://`指令，将后端响应中的Location头协议自动修正。当架构中Nginx前存在负载均衡器时，需由负载均衡器透传`X-Forwarded-Proto`头，同时将Nginx配置中相关的`$scheme`变量替换为`$http_x_forwarded_proto`，以正确识别和传递最前端的访问协议。

IT 累计浏览 2,460

PHPTS：一键免费搭建 Nginx + PHP + MySQL + Redis + Memcached 网站、APP、小程序服务器端运行环境

这篇讲的是如何在 Windows 上快速搭建网站服务器环境。传统方式需要手动安装和配置 Nginx、PHP、MySQL 等一堆组件，过程繁琐且容易出错，尤其是官方 Nginx for Windows 版本在连接数和性能模型上限制明显，往往只能用于测试。文章介绍的 PHPTS 软件给出了一个“一键搞定”的方案。它将上述组件集成为一个安装包，并对关键的 Nginx 进行了深度优化——采用了 Windows IOCP 模型并支持多进程，将连接数上限从官方版本的 1024 大幅提升至 32768，使其在 Windows 上也能胜任生产环境。这解决了长期困扰 Windows 开发者的性能痛点。除了作为本地开发环境，软件还定位为边缘计算平台。它可以运行在各类本地设备上，利用本地算力完成 AI、音视频处理等任务，减少对公有云的依赖，并支持与云服务组建混合云。对于需要在 Windows 下快速启动 Web 服务或探索本地化部署的开发者来说，这提供了一个免费且开箱即用的选择。

IT 累计浏览 2,661

如何快速实现一个基于 Nginx 网站的监控场景

这篇文章讲述了小明在一家电商创业公司，如何从零开始构建基于Nginx的服务监控体系，并最终转向一站式云产品的实践历程。故事的起点是老板提出的明确需求：要能实时统计服务调用次数与返回码、实现阈值报警，并支持灵活的历史查询，同时要求系统具备良好的扩展性和成本控制。小明在对比了传统OLAP、搜索引擎和实时计算方案后，选择了自研实时计算架构，并详细设计了包含数据通道、计算引擎、存储和展示门户的完整链路。然而，理想丰满，现实骨感。在长达两个月的开发过程中，小明遭遇了一系列典型痛点：多组件集成排查困难、Nginx日志清洗繁琐、为防数据重复计算而设计的存储幂等性问题、延迟数据如何合并、以及如何高效遍历所有服务进行报警检查等。这些挑战导致项目进度严重滞后。转机来自一次与师兄的交流。小明了解到阿里云ARMS这款产品，它采用“实时计算+列式存储”架构，将日志采集、实时聚合、报警和可视化报表集成于一体。对于小明最核心的Nginx监控场景，ARMS提供了开箱即用的模板，只需在日志格式中加入如`$request_time`等字段即可快速接入。它不仅能直接提供监控大盘和报警功能，还开放了API，便于业务系统直接对接数据，从而将小明从繁琐的底层开发中解放出来。

IT 累计浏览 1,921

HTTPS 常见部署问题及解决方案

这篇文章整理了作者在 HTTPS 和 HTTP/2 部署实践中收集的典型故障与解决方案，堪称一份实用的排错手册。遇到问题时，作者推荐首先使用 Qualys SSL Labs 的在线测试工具进行诊断。针对 Let's Encrypt 证书申请验证失败的情况，文章建议改用 acme.sh 的 DNS 验证模式，通常能绕过服务器访问限制。对于 Chrome 53 浏览器报告的 ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 错误，根因是 Chrome 的一个 Bug，解决方案是升级浏览器版本。当浏览器提示证书错误时，文章指出需检查证书链的完整性，特别是不要遗漏中间证书。如果问题仅出现在老旧浏览器（如 IE8），则很可能是未启用 SNI（服务器名称指示）导致，可通过将站点部署在不同服务器、使用 SAN 证书或直接忽略这些旧浏览器来解决。启用 HTTP/2 后访问异常（如 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY），通常是因为 CipherSuite 配置不当，可参考 Mozilla 或 CloudFlare 的权威配置进行调整。若浏览器在 Nginx 启用 HTTP/2 后仍降级为 HTTP/1.1，则可能是 OpenSSL 版本过低（低于 1.0.2）不支持 ALPN 协议协商所致。最后，升级 HTTPS 后网站部分资源无法加载，原因往往是混用了 HTTP 资源，解决方案是确保所有外链资源均使用 HTTPS 协议。文章内容会持续更新，为开发者提供了具体的排查思路和改进方案。

IT 累计浏览 3,600

PHP返回内容过长时被nginx截断的解决办法

这篇讲的是作者升级博客环境后，发现后台编辑器界面莫名“消失”——页面内容被截断，功能完全无法使用。他没有急于胡乱配置，而是沉下心分析问题。排查过程一度很曲折，从复杂的网络抓包入手绕了远路，但最终从 nginx 的错误日志中找到了关键线索：一行 `Permission denied` 错误。原来，当 PHP 返回的响应内容过大时，nginx 会先将其缓存到本地临时文件中，但由于该临时目录（`/var/lib/nginx/tmp/fastcgi/`）的权限不正确，nginx 无法写入文件，从而导致连接中断、内容截断。解决方案其实很简单：将该目录的权限修改为 775。作者复盘时指出，这次本可快速解决的问题耗费了大量时间，核心教训是：面对异常，应当优先检查系统日志、基于线索推理，而非凭借假设盲目测试。一次具体的踩坑经历，清晰地揭示了 PHP 与 nginx 协作时一个容易被忽略的权限配置细节。

IT 累计浏览 2,622

Nginx配置$request_uri与$uri变量的区别

这篇讲的是在Nginx配置中两个极易混淆的变量：$request_uri 与 $uri 的核心区别。文章从一个实际现象出发：浏览器请求同一个地址，这两个变量的值却可能不同。关键差异在于它们代表的“时间点”。$request_uri 记录的是客户端发起请求时最原始的路径与查询字符串，比如 /my/act?a=1，是“未处理”的状态。而 $uri 则是Nginx处理请求后，最终定位到服务器上资源的路径，比如经过rewrite规则变成 /dir/file.php，它不包含查询参数。文章特别指出，$request_uri 这个名字本身容易造成误解，因为按标准定义，URI并不包含查询字符串，但它却包含了。理解这个区别至关重要：当你需要记录或匹配客户端最初的原始请求时，应使用 $request_uri；而当你需要基于经过内部重写后的实际资源位置进行逻辑判断或记录日志时，则应使用 $uri。搞混两者可能导致rewrite规则失效或日志记录不准确。

IT 累计浏览 802

从启用 HTTP/2 导致网站无法访问说起

这篇讲的是网站升级到 HTTP/2 后反而无法访问的典型案例。作者从朋友遇到的具体故障出发——启用 HTTP/2 后 Chrome 报「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」错误，Firefox 直接中断请求，而关闭 HTTP/2 则一切正常。问题的根源在于 HTTP/2 协议对 TLS 有更严格的安全限制。它强制要求使用 TLSv1.2 或更高版本，并禁用了一大批在旧协议中可用的加密套件（CipherSuite）。当服务端配置的 CipherSuite 列表被包含在 HTTP/2 的黑名单中时，浏览器在 TLS 握手阶段就会直接终止连接，导致页面无法加载。文章通过 Wireshark 抓包和具体的 Nginx 配置示例，清晰地展示了这一协商失败的过程。对于遇到类似问题的开发者，这篇不仅提供了调整 CipherSuite 配置的直接解法，更重要的是梳理了从现象到本质的排查思路，值得参考。

IT 累计浏览 3,143

wordpress/nginx安全设置

这篇讲的是如何给WordPress博客加固登录安全，作者从两个实战层面入手：插件增强认证与通信链路加密。首先，文章详细演示了如何通过Google Authenticator插件为WordPress登录添加双重验证。这类似于谷歌账户的“两步验证”，原理是在密码之外，增加一道由手机App动态生成的验证码，能有效防范密码泄露风险。作者还梳理了其他类似安全插件，如一次性密码、IP锁定等，提供了更全面的选择思路。其次，更进阶的一步是配置Nginx反向代理下的SSL（HTTPS）登录。作者不仅说明了如何在WordPress配置文件中启用强制SSL，还提供了从生成自签名证书到编写完整Nginx配置的全过程。过程中特别指出了一个典型坑点：Nginx配置不当会导致后台CSS文件的MIME类型错误，并给出了具体的修正配置，这部分对实际操作很有参考价值。整个方案从认证加固到传输加密，层层递进，解决的是WordPress站点常见的登录安全隐患，过程细节扎实，踩坑点清晰。

IT 累计浏览 2,022

从无法开启 OCSP Stapling 说起

这篇讲的是，作者从读者常问的“为什么在Nginx中配置了 ssl_stapling on 却没生效”这个问题出发，深入剖析了OCSP Stapling的原理与实操。文章先简要回顾了OCSP（在线证书状态协议）会拖慢TLS握手，而OCSP Stapling（让服务端主动提供状态）是优化这一过程的关键。接着，作者没有停留在理论，而是手把手教读者一个轻量的排查方法：使用openssl命令行工具进行验证。通过一条具体命令和对输出结果的解读（比如看到“OCSP Response Status: successful”就说明已开启），读者可以快速自检，而无需等待SSL Labs的漫长检测。文章进一步深入，展示了完整的OCSP Response内容，并解释了其由“验证数据”和“签名证书”两部分组成。最后，文章还指导读者如何在本地获取证书链并主动查询OCSP信息，从原理层面帮助开发者真正理解这一机制，而不仅仅是配置一行代码。

IT 累计浏览 2,001

从 Nginx 默认不压缩 HTTP/1.0 说起

这篇讲的是，Nginx 默认只为 HTTP/1.1 启用 GZip 压缩，而对 HTTP/1.0 请求关闭压缩，这背后并非配置疏忽，而是 HTTP 协议特性在服务端实现中的一个关键权衡。文章从移动端异常高比例的 HTTP/1.0 流量这一现象切入，深入剖析了原因。Nginx 默认采用即时压缩（On-The-Fly Compression）以优化首字节时间，但这导致无法预知响应大小，无法设置 Content-Length。在 HTTP/1.0 中，没有 HTTP/1.1 的 Transfer-Encoding: chunked 分块传输机制，客户端只能依靠 Content-Length 或断开连接来判断结束。因此，Nginx 为了在 HTTP/1.0 上尽可能保持持久连接（keep-alive），默认选择了放弃压缩。一旦启用 HTTP/1.0 压缩，Nginx 就只能返回 Connection: close 来结束传输。文章通过对比测试验证了这一机制，并给出了务实建议：对于动态内容（如 PHP 输出的 HTML），因其本身无法预知大小，不妨启用 GZip 以节省流量；对于可预知大小的静态文件（JS、CSS），则建议将关键资源内联，非关键资源用外链并启用压缩，接受连接断开以换取流量节省。一个看似简单的 Nginx 配置，背后其实是 HTTP/1.0 与 1.1 在协议能力上的深刻差异。

IT 累计浏览 1,061

“NodeJS在大搜车” 之应用部署篇

作者从团队实际需求出发，分享了NodeJS应用在大搜车的部署实践。文章的核心在于解决不同环境下Node进程的稳定管理与高效部署问题。针对工具选型，作者解释了为何线上环境选用功能全面、进程管理更稳定的PM2，而在需要频繁变更端口的测试环境，则采用更轻量灵活的Forever。本地开发则配合nodemon实现代码热更新。这套组合策略平衡了稳定性与灵活性。在环境划分上，文章详细介绍了测试、预发、生产三套环境各自的作用与配置。生产环境依托阿里云ECS、SLB、RDS等一整套云服务，基本免除了底层运维烦恼。部署流程则通过自定义Bash脚本实现：从代码拉取、打包上传，到服务器上的解压、备份、覆盖及PM2重启，整个过程在预发服务器上执行，并通过间隔部署配合负载均衡，确保线上服务零宕机。文章最后坦诚，这套部署体系仍在不断进化，未来计划引入Docker优化测试环境，并着手应对多环境自动部署、性能优化等新挑战。

IT 累计浏览 4,923

HTTPS证书生成原理和部署细节

这篇讲的是 HTTPS 是如何保障通信安全的，以及我们该如何亲手生成和部署证书。文章从一个生动的电信用户遭遇 DNS 劫持、被注入广告的案例切入，点明了在 HTTP 明文传输下隐私暴露的风险。作者详细拆解了 HTTPS 的核心安全机制：它在 HTTP 基础上增加了加密、认证和鉴定。通过一张流程图和清晰的步骤，文章描述了客户端与服务器如何通过交换随机数并生成会话密钥（session key）来建立安全通道。同时，文章也指出了仅有非对称加密不够，必须引入受信任的第三方 CA 来签发数字证书，以防中间人攻击。文章进一步科普了 CA 证书的三种验证等级（DV、OV、EV），并提供了实操部分：使用 OpenSSL 命令从生成密钥对、创建 CA 根证书，到最终签发服务器证书的完整流程。最后，对于个人或小型站点，文章也提到了自签名证书这一低成本解决方案。整体上，这是一篇从原理到实践的指南，既解释了“为什么需要 HTTPS”以及“它是如何工作的”，也手把手教你“如何自己动手做”。

IT 累计浏览 3,220

使用varnish + nginx + lua搭建网站的降级系统

这篇文章讲的是如何用Varnish、Nginx和Lua脚本搭建一个网站降级系统，核心目标是在数据库等后端服务出现致命故障（如500错误）时，能自动切换到展示缓存的静态页面，从而维持最基本的浏览功能。作者首先明确了降级方案的三个关键点：只提供基础浏览、数据为非登录状态、支持手动与自动触发。整个系统的存储层由Varnish承担，利用其内存缓存来平衡性能与资源。为了保持缓存数据的时效性，作者设计了一个异步更新机制：通过crond定时任务分析Nginx的access日志，提取出热门请求URL，再主动向Varnish发起请求以刷新对应缓存，从而减轻了主站的压力。降级的触发与切换逻辑主要通过Nginx结合Lua脚本来实现。在Nginx中，通过Lua脚本检查一个共享内存字典中的降级状态标志。一旦进入降级模式，所有PHP动态请求会被重定向，直接从Varnish获取数据返回给用户。自动降级功能则通过监控后端健康状态来实现，例如，当后端监控脚本返回500错误时，Varnish和Nginx都能自动感知并进入降级状态；恢复正常后，系统也会自动切换回来。管理员还可以通过特定的接口进行手动降级操作。文章详细给出了从Varnish安装、Lua脚本部署到Nginx配置修改的完整步骤，并提供了相关的配置文件和脚本下载。对于需要保障高可用性的Web服务，这套结合了缓存、负载与动态逻辑切换的降级方案，提供了一个清晰且可落地的实践参考。

IT 累计浏览 2,200

Ghost+Nginx部署HTTP2

这篇讲的是作者为抵抗运营商劫持，在Ghost博客上部署HTTPS与HTTP/2的实战全过程。核心方案围绕Nginx代理与SSL证书展开：最初尝试免费的Let's Encrypt证书，但因DNS验证问题放弃，转而选用商业Comodo证书；Nginx需升级至mainline版本以支持http2，并在监听配置中显式添加http2参数。部署后遇到混合内容（mixed content）导致浏览器警告，关键解决方案是将子域名的图片路径迁移至主域下，通过Nginx的alias规则统一提供服务，并配置了HTTP到HTTPS的301跳转。整个过程验证了HTTPS/HTTP/2对防御劫持的有效性，同时也指出了SHA-2证书对旧版IE和Android的兼容性限制。文章记录了从证书选择、Nginx调优到内容迁移的完整踩坑与解决思路，对同类博客升级有直接参考价值。

IT 累计浏览 4,441

“集群和负载均衡”的通俗版解释

这篇讲的是“集群”和“负载均衡”这两个常被提及却未必真懂的计算机技术概念。作者没有堆砌术语，而是从实际困惑出发，力求用最通俗的语言帮大家理清它们。文章核心是通过生活化的比喻来拆解技术。比如，用“超市收银员高峰期增开出口”来解释负载均衡的核心——“分摊压力”；用“兄弟开裁缝铺接单、做手工家具”的故事，生动区分了负载均衡集群、高可用集群与高性能计算集群的不同目标和工作方式。这种写法让抽象概念立刻变得可感可知。作者不仅解释了基本概念，还对比了三种主要集群类型在解决“分摊任务”、“保障持续服务”、“并行复杂运算”等不同场景问题时的侧重点。文章最后也点明了这类知识的实践门槛，强调了从架构、运维到开发视角的差异。它像一份清晰的技术概念地图，帮助读者快速建立直观理解。对于那些常听到这些词但一直没机会系统梳理的开发者和技术爱好者，这种深入浅出的解读正是所需的入门钥匙。

IT 累计浏览 3,620

nginx 利用 rewrite 屏蔽IE浏览器

这篇讲的是前端开发中让人头疼的IE兼容性问题，作者从运维的角度切入，提供了一套通过Nginx rewrite规则直接屏蔽特定版本IE浏览器的配置方案。具体来说，文章核心是利用Nginx的 `$http_user_agent` 变量，通过正则表达式匹配用户访问时携带的浏览器标识。例如，配置中示例的规则会拦截IE6到IE9版本的请求，并利用 `rewrite /ie.html break;` 指令，将这些请求重定向到一个静态的提示页面，从而避免前端因处理老版本IE而产生的额外工作。文章不仅给出了可以直接使用的配置实例，还逐一解释了 `$http_user_agent`、`~*`、`MSIE` 以及 `break` 等关键参数的具体含义，让读者理解每一条配置背后的逻辑。为了方便验证效果，作者还推荐了IETester这款工具来模拟不同版本的IE环境。此外，文章末尾整理了一份Nginx全局变量的速查列表，这不仅能帮助理解当前案例，也为读者在其他场景下灵活运用Nginx的重写模块提供了实用参考。整体来看，这是一个针对特定问题的轻量但有效的解决方案，兼顾了实操性与原理说明。

IT 累计浏览 3,400

nginx访问控制Access Control的问题

这篇讲的是nginx中一个容易踩的坑：使用`allow`和`deny`配置IP访问控制时，规则可能出乎意料地“不生效”。作者通过一个实际配置进行测试：在server块禁用了IP `211.81.175.6`，在`location /nginxacc`块禁用了IP `211.81.175.8`。预期结果是前者全站不可访问，后者仅目录受限。但实际测试发现，IP `211.81.175.6`竟然能访问`/nginxacc`，而IP `211.81.175.8`却可以访问根目录。问题的根因在于nginx的访问控制规则继承机制。如果子级（如location块）定义了任何ACL规则，它就**不会**继承父级（如server块）的规则，而是完全使用自己定义的规则列表。这意味着，虽然IP `211.81.175.6`在server层被禁，但在`/nginxacc`这个location里没有重新声明禁止，因此该location的访问是被放行的。文章引用了nginx源码作为依据。这个发现提醒我们，在设计多层级访问控制时，必须清楚理解规则的继承与覆盖逻辑，不能想当然地认为规则会自动累加。否则就可能出现安全策略漏洞，本该封锁的IP反而获得了访问权限。

IT 累计浏览 6,820

nginx上，http状态200响应，PHP空白返回的问题

这篇讲的是在Nginx+PHP-FPM环境中，一个颇为诡异的故障：PHP脚本返回HTTP 200状态码，但页面内容却完全为空白。作者从朋友的一个求助问题出发，记录了完整的排查与解决过程。故障排查从怀疑PHP扩展冲突开始，但尝试关闭xdebug等扩展后问题依旧。通过`strace`分析系统调用，作者捕捉到了关键的线索——FastCGI请求包中，竟然缺少了必需的`SCRIPT_FILENAME`变量。这导致PHP-FPM无法定位和执行真正的PHP脚本文件。文章随后深入PHP-FPM源码，解释了当`SCRIPT_FILENAME`缺失时，其内部的处理逻辑正是直接返回一个空的响应体。问题的根源随之清晰：Nginx在将请求转发给PHP-FPM时，没有正确传递这个关键变量。最终，通过调整Nginx的FastCGI配置，确保`SCRIPT_FILENAME`被正确设置，问题得以解决。这篇记录不仅解决了一个具体问题，也揭示了Nginx与PHP-FPM交互协议中一个容易被忽略的细节，对于排障思路的梳理很有启发。

IT 累计浏览 2,180

nginx的SCRIPT_NAME, PATH_INFO多了index.php问题

这篇讲的是nginx配置中一个常见的坑：在设置反向代理后，PHP获取到的`SCRIPT_NAME`和`PATH_INFO`变量不正确，把整个URI路径都带上了。比如访问`/index.php/site/login`时，`SCRIPT_NAME`本应是`index.php`，却拿到了完整的路径字符串。作者定位到问题出在正则表达式定义的`location`块配置不完整。核心解决思路是，需要将请求的URI明确拆解为“脚本文件名”和“附加路径信息”两部分。通过新增一个专门匹配`.php($|/)`的`location`块，并利用正则捕获组`"^(.+.php)(/.+)"`，就能精准地把`index.php`赋值给`$script`，把后面的`/site/login`赋值给`$path_info`。最终，通过`fastcgi_param`指令将正确拆解后的值传递给PHP处理，使得`$_SERVER['SCRIPT_NAME']`和`$_SERVER['PATH_INFO']`能获得预期的值，保证了框架路由能正常工作。这个配置方法清晰地展示了如何在nginx层面解决路径解析歧义。

IT 累计浏览 2,860

Nginx带宽控制

这篇讲的是作者如何用Nginx替代Squid来实现文件下载的带宽控制。他首先介绍了Nginx自带的 `limit_rate` 和 `limit_rate_after` 指令，可以轻松设置“下载超过500KB后限速50KB/s”的规则。但挑战在于，这是单连接限速。如果想控制总带宽（比如总出口100M），单纯限制每个连接速度并不够灵活，无法应对用户数变化带来的动态调整。为此，文章组合使用了 `limit_conn` 模块来限制并发连接数，从而变相控制总带宽，并分析了这种方案的局限性。文章还探讨了更根本的解决方案：使用第三方 `limit_speed` 模块，或者借助Linux底层强大的TC命令进行流量整形（尽管配置复杂）。结尾处，作者推荐了功能相关但场景不同的 `limit_req` 模块。整体来看，文章从一个实际需求出发，梳理了Nginx在带宽控制方面的多种能力与边界，提供了不同复杂度下的实践思路。