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

34 | 如何使用Nginx搭建最简单的直播服务器?

在前面三篇文章中,我们介绍了传统直播系统架构、HLS 协议、RTMP 协议相关的知识,那今天我们就来具体实操一下,根据前面所学到的知识搭建出一套最简单的音视频直播系统。
今天我们要搭建的这套直播系统相较于《31 | 一对多直播系统 RTMP/HLS,你该选哪个?》一文中介绍的直播系统要简单得多。该系统不包括客户端、没有 CDN 分发,只包括最基本的推流、转发及拉流功能。虽然它简单了一点,但麻雀虽小五脏俱全,通过这样一个实战操作,我们就可以将前面讲解的理论与实际结合到一起了。
当然,作为一个直播系统来说,客户端是必不可少的。但由于时间和篇幅的原因,我们只能借助一些现成的或者开源的客户端对我们的直播系统进行测试了,所以客户端的界面可能会简陋一些。也正因为如此,我才没有将它们算作咱们这个直播实验平台之中。
实际上,我们完全可以以这个直播系统实验平台为原型,逐步地将一些功能添加进去,这样很快就可以构建出一套商业可用的传统直播系统了。

直播系统架构

在正式开始实战之前,我们先来简要介绍一下这个直播系统的架构,如下图所示:
最简单的直播系统
这个直播架构非常简单,由两部分组成,即媒体服务器客户端
媒体服务器有两个功能:
推流功能,可以让客户端通过 RTMP 协议将音视频流推送到媒体服务器上;
拉流功能,可以让客户端从媒体服务器上拉取 RTMP/HLS 流。
实际上,这个架构与我们前面介绍的传统直播架构相比是有变化的,减少了信令服务器,同时将 CDN 网络变成了一台流媒体服务器。但理解了整个直播架构的原理后,我们就可以快速地将这个简单的直播架构恢复成一个正式的、可商用的直播系统。
那对于我们这个简化的直播系统来说,如何实现架构中的媒体服务器呢?
这里我们使用了目前最流行的 Nginx 来实现它。之所以选用 Nginx 主要出于以下两方面的原因:
Nginx 的性能是很优越。在众多的
                

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

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

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

        

2W 字总结 !体系化带你全面认识 Nginx

前言

作为一名开发人员,你是不是经常碰到领导让你上服务器去修改 Nginx 配置,然而你会以“我是开发,这个我不会”为理由搪塞过去呢!今天就让我们一起告别这种尴尬,向“真正”的程序员迈进!!!

Nginx 概述

图片

Nginx 是开源、高性能、高可靠的 Web 和反向代理服务器,而且支持热部署,几乎可以做到 7 * 24 小时不间断运行,即使运行几个月也不需要重新启动,还能在不间断服务的情况下对软件版本进行热更新。性能是 Nginx 最重要的考量,其占用内存少、并发能力强、能支持高达 5w 个并发连接数,最重要的是, Nginx 是免费的并可以商业化,配置使用也比较简单。…