Nginx

在 CentOS 7 上从源代码编译安装 Nginx

您可能需要比存储库中的版本更新的 Nginx 版本。截至今日(2019 年 4 月 30 日),最新版本为 1.16.0。Nginx 开发人员维护一个最新版本的 yum 存储库。我建议使用存储库,因为它更容易使 Nginx 保持最新。Nginx Linux 软件包页面解释了如何将其存储库添加到您的系统并从中安装 Nginx。如果您仍希望从源代码安装,请继续阅读。

    

Nginx修改默认Content-Type值,解决服务器文件没有扩展名时变为下载的问题

1、Nginx 安装之后 default_type的值默认配置为 application/octet-stream,而且目前已经配置很多域名,贸然的去修改这样的全局配置,可能应发不可用的问题

2、html结尾的文件,放到网站根目录下默认会被识别响应为 text/html.

3、但是今天反馈的文件是没有后缀的,所以默认就成了 application/octet-stream, 浏览器请求会直接进行下载,而不是展示文件内容

4、针对该文件进行单独的配置,如下

server {
    include local_ssl_port.conf;
    include ssl/ssl.conf;
    server_name    xxx.somedomain.com;
    root    /data/project/blog;
    include         expires.conf;

    location / {
        # 这里单独针对性的配置 default_type 为要求的格式
        default_type text/html;
    }
}

 

5、再次浏览器测试,展示为文件内容

    

nginx启用proxy cache 代理缓存

nginx启用proxy cache 代理缓存

nginx.conf中的
http {
下面加

proxy_cache_path /data/nginxcache levels=1:2 keys_zone=my_cache:500m max_size=10g inactive=30d use_temp_path=off;

某个站点的配置文件中增加以下配置:

location / {

proxy_cache my_cache;
proxy_cache_revalidate on;
#proxy_cache_valid 200 206 304 301 302 30d;
proxy_cache_valid any 30d;
proxy_ignore_headers "Set-Cookie";
proxy_ignore_headers "Expires";
#proxy_ignore_headers "Age";
proxy_cache_key …

                

网页出现400 Bad Request Request Header Or Cookie Too Large错误的解决方法

在开发项目过程中,突然遇到400 Bad Request Request Header Or Cookie Too Large的报错,我也是第一次出现这样的错误,感觉还是挺新奇的。

分析下出现错误的原因:

由request header过大所引起,request过大,通常是由于cookie中写入了较大的值所引起的。

解决办法:

 

采用nginx服务器的话修改方法:

/usr/local/nginx/conf

在这个路径下面,修改nginx.conf

http
{

include  mime.types;
default_type  application/octet-stream;
server_names_hash_bucket_size 128;
client_header_buffer_size 16k;  //这里默认是4K,改大一点就好了
large_client_header_buffers 4 32k;  //改大一点就好了 } 实例配置: 
http
{

**********

client_header_buffer_size 
    

nginx 流媒体服务器,nginx tcp http负载均衡,nginx 流转发,nginx 推流,nginx rtmp

用到了   https://github.com/winshining/nginx-http-flv-module

nginx 流媒体服务器,nginx tcp http负载均衡,nginx 流转发,nginx 推流,nginx rtmp

user www-data;
worker_processes auto;
pid /run/nginx.pid;
#worker_cpu_affinity  auto; #1.9.10 以及之后的版本

include /etc/nginx/modules-enabled/*.conf;

load_module modules/ngx_http_flv_live_module.so;


worker_rlimit_nofile 200000;


events {
  worker_connections 10240;
  #multi_accept on;
}

http {

  ##
  # Basic Settings
  
    

为 NGINX 和 NGINX Plus 编译第三方动态模块

编辑器 - 宣布动态模块支持的原始版本(在 NGINX 开源 1.9.11 中,2016 年 2 月)的博客文章重定向到这里。该帖子中描述的构建过程已被弃用。

这篇文章是关于在 NGINX Open Source 和 NGINX Plus 中使用第三方动态模块的两部分系列文章的一部分。

  • 这篇文章提供了编译第三方动态模块的分步说明,这些模块可以在运行时由 NGINX Open Source 或 NGINX Plus 加载。
  • 第二篇文章提供了为生产环境自动构建第三方动态模块的指导和工具。它解释了如何为包括版本依赖性检查的第三方动态模块创建可安装包。

NGINX Open Source 1.11.5 和NGINX Plus Release R11引入了动态模块的二进制兼容性。本文解释了如何编译第三方模块以在开发环境中与 NGINX Open

使用内核 TLS 和 SSL_sendfile() 提高 NGINX 性能

传输层安全 (TLS) 是一种非常流行的加密协议。在内核 (kTLS) 中实现 TLS 通过显着减少用户空间和内核之间的复制操作需求来提高性能。

结合 kTLS 和sendfile()意味着数据在传递到网络堆栈进行传输之前直接在内核空间中加密。这消除了将数据复制到用户空间以通过 TLS 库加密,然后再返回内核空间进行传输的需要。kTLS 还支持将 TLS 处理卸载到硬件,包括将 TLS 对称加密处理卸载到网络设备。…

        

使用 NGINX 将环境变量注入静态网站

静态站点生成非常适合发布文档。在最近的一个项目中,我们选择使用 NGINX 作为 Web 服务器来托管 HTML 和 CSS 文件。但是,我们还希望使用 SSO 保护站点。这就是事情变得有点困难的地方。

当然,当使用 HTTP 基本身份验证以外的 SSO 机制时,我们需要向用户显示“退出”按钮。但是当与静态站点生成 (SSG) 结合使用时,我们还不知道注销 URI,因为它可能取决于部署的特定配置。

为了实际渲染按钮,我们面临两个选择:

  1. 不在 CI 中运行 SSG 工具,而是在 Docker 容器启动时运行。
  2. 呈现没有 URI 的链接,并让 Web 服务器在运行时注入它。

在我们的例子中,SSG 工具是 Jekyll,所以添加它的整个 Ruby 工具链会违背使用 NGINX 的目的:尽可能轻量级。此外,这个巨大的图像会创造更多的攻击面。[1]