ngınx ile Linux üzerinde ana bilgisayar ASP.NET Core

, Sourabh Shirhatti

bu kılavuzda ubuntu 16,04 sunucusunda üretime hazır ASP.NET Core ortamı ayarlama açıklanmaktadır. Bu yönergeler büyük olasılıkla Ubuntu 'ın daha yeni sürümleriyle çalışır, ancak yönergeler daha yeni sürümlerle sınanmamıştır.

ASP.NET Core tarafından desteklenen diğer Linux dağıtımları hakkında daha fazla bilgi için bkz. Linux üzerinde .net Core önkoşulları.

Bu kılavuz:

• mevcut bir ASP.NET Core uygulamasını bir ters proxy sunucusunun arkasına koyar.
• İstekleri Web sunucusuna iletmek için ters proxy sunucusunu ayarlar Kestrel .
• Web uygulamasının, bir arka plan programı olarak başlangıcında çalışmasını sağlar.
• Web uygulamasını yeniden başlatmanıza yardımcı olması için bir işlem yönetim aracı yapılandırır.

Önkoşullar

• Sudo ayrıcalığına sahip standart bir kullanıcı hesabı ile Ubuntu 16,04 sunucusuna erişim.
• Sunucuda yüklü olan en son önizleme sürümü olmayan .NET çalışma zamanı .
• mevcut bir ASP.NET Core uygulaması.

paylaşılan framework 'ü yükselttikten sonra gelecekte herhangi bir noktada, sunucu tarafından barındırılan ASP.NET Core uygulamaları yeniden başlatın.

Uygulama üzerinde Yayımla ve Kopyala

Uygulamayı çerçeveye bağımlı bir dağıtımiçin yapılandırın.

Uygulama yerel olarak çalıştırılır ve güvenli bağlantı (HTTPS) yapmak üzere yapılandırılmamışsa aşağıdaki yaklaşımlardan birini benimseyin:

• Uygulamayı güvenli yerel bağlantıları işleyecek şekilde yapılandırın. Daha fazla bilgi için https yapılandırma bölümüne bakın.
• https://localhost:5001Dosyadaki özelliğinden (varsa) kaldırın applicationUrl Properties/launchSettings.json .

Bir uygulamayı bir dizine paketlemek için geliştirme ortamından DotNet Publish çalıştırın (örneğin, bin/Release/{TARGET FRAMEWORK MONIKER}/publish yer tutucu {TARGET FRAMEWORK MONIKER} hedef Framework bilinen adı/tfd) sunucuda çalıştırılabilir:

dotnet publish --configuration Release

Uygulama, sunucuda .NET Core çalışma zamanının bakımını yapmayı tercih ediyorsanız, kendi kendine içerilen bir dağıtım olarak da yayımlanabilir.

ASP.NET Core uygulamasını, kuruluşun iş akışını (örneğin,) tümleştiren bir aracı kullanarak sunucuya kopyalayın SCP SFTP . varDizinde (örneğin,) Web uygulamalarının yerini bulmak yaygındır var/www/helloapp .

Uygulamayı test etme:

1. Komut satırından uygulamayı çalıştırın: dotnet <app_assembly>.dll .
2. Bir tarayıcıda, http://<serveraddress>:<port> uygulamanın Linux üzerinde yerel olarak çalıştığını doğrulamak için bölümüne gidin.

Ters proxy sunucu yapılandırma

Ters proxy, dinamik Web uygulamaları sunmak için ortak bir kurulumtir. ters proxy, HTTP isteğini sonlandırır ve ASP.NET Core uygulamasına iletir.

Ters proxy sunucusu kullanma

KestrelASP.NET Core ' dan dinamik içerik sunmak için idealdir. Ancak, Web 'e sunma özellikleri IIS, Apache veya NGINX gibi sunucu olarak zengin özellik değildir. Ters bir ara sunucu, statik içerik sunma, istekleri önbelleğe alma, istekleri sıkıştırma ve HTTP sunucusundan HTTPS sonlandırması gibi işleri devreedebilir. Ters ara sunucu, ayrılmış bir makinede bulunabilir veya bir HTTP sunucusu ile birlikte dağıtılabilir.

Bu kılavuzun amaçları doğrultusunda, tek bir NGINX örneği kullanılmıştır. Bu, HTTP sunucusu ile birlikte aynı sunucuda çalışır. Gereksinimlere bağlı olarak, farklı bir kurulum seçilebilir.

İstekler ters proxy tarafından iletileceği için, paketten Iletilen üstbilgiler ara yazılımını kullanın Microsoft.AspNetCore.HttpOverrides . Ara yazılım, Request.Scheme üstbilgiyi kullanarak, X-Forwarded-Proto yeniden yönlendirme URI 'leri ve diğer güvenlik ilkelerini doğru çalışacak şekilde güncelleştirir.

İletilen üstbilgiler ara yazılımı, diğer ara yazılım öncesinde çalıştırılmalıdır. Bu sıralama, iletilen üst bilgi bilgilerine bağlı olan ara yazılımın işleme için üst bilgi değerlerini kullanmasını sağlar. Tanılama ve hata işleme ara yazılımı sonrasında Iletilen üstbilgiler ara yazılımını çalıştırmak için bkz. Iletilen üstbilgiler ara yazılım sırası.

UseForwardedHeaders Startup.Configure Diğer ara yazılım çağrılmadan önce yönteminin en üstünde yöntemi çağırın. Ara yazılımı, X-Forwarded-For ve üst bilgilerini iletecek şekilde yapılandırın X-Forwarded-Proto :

using Microsoft.AspNetCore.HttpOverrides;

...

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Hayır ForwardedHeadersOptions , ara yazılım için belirtilmemişse, iletmek için varsayılan üstbilgiler şunlardır None .

127.0.0.0/8 [::1] Standart localhost adresi () de dahil olmak üzere geri döngü adreslerinde çalışan proxy 'ler, 127.0.0.1 Varsayılan olarak güvenilirdir. Kuruluş içindeki diğer güvenilir proxy 'ler veya ağlar, Internet ve Web sunucusu arasında istekleri ele alıyorsa, bunları KnownProxies veya ile listesine ekleyin KnownNetworks ForwardedHeadersOptions . Aşağıdaki örnek, içindeki Iletilen üstbilgiler ara sunucusuna alana 10.0.0.100 IP adresinde bir güvenilen ara sunucu ekler KnownProxies Startup.ConfigureServices :

using System.Net;

...

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Daha fazla bilgi için bkz. Yapılandırma ASP.NET Core sunucuları ve yük dengeciler ile çalışacak şekilde yapılandırma.

NGINX 'i yükler

apt-getNGINX yüklemek için kullanın. Yükleyici, systemd sistem başlangıcında arka plan programı olarak Nginx çalıştıran bir init betiği oluşturur. NGINX: resmi deni/Ubuntu paketlerindeUbuntu yükleme yönergelerini izleyin.

NGINX ilk kez yüklendiğinden bu yana şunu çalıştırarak açık olarak başlatın:

sudo service nginx start

Bir tarayıcının NGINX için varsayılan giriş sayfasını görüntülediğini doğrulayın. Giriş sayfasına adresinden ulaşılabilir http://<server_IP_address>/index.nginx-debian.html .

Nginx hizmetini yapılandırma

HTTP isteklerini ASP.NET Core uygulamanıza iletmek için ngınx 'i ters proxy olarak yapılandırmak için değiştirin /etc/nginx/sites-available/default . Bu dosyayı bir metin düzenleyicisinde açın ve içeriğini aşağıdaki kod parçacığıyla değiştirin:

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Uygulama bir SignalR veya Blazor Server uygulama ise, SignalRASP.NET Core üretim barındırma ve ölçeklendirme ASP.NET Core barındırma ve dağıtma Blazor Server daha fazla bilgi için bkz. ve.

Hiçbir server_name eşleşme olmadığında NGINX varsayılan sunucuyu kullanır. Varsayılan sunucu tanımlanmazsa, yapılandırma dosyasındaki ilk sunucu varsayılan sunucusudur. En iyi uygulama olarak, yapılandırma dosyanızda 444 durum kodunu döndüren belirli bir varsayılan sunucu ekleyin. Varsayılan bir sunucu yapılandırma örneği:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

NGINX yapılandırması kurulduktan sonra, sudo nginx -t yapılandırma dosyalarının söz dizimini doğrulamak için ' i çalıştırın. Yapılandırma dosyası testi başarılıysa, NGINX ' i çalıştırarak değişiklikleri çekmeye zorlayın sudo nginx -s reload .

Uygulamayı sunucuda doğrudan çalıştırmak için:

1. Uygulamanın dizinine gidin.
2. Uygulamayı çalıştırın: dotnet <app_assembly.dll> , burada app_assembly.dll uygulamanın derleme dosyası adıdır.

Uygulama sunucuda çalışır, ancak Internet üzerinden yanıt vermezse, sunucunun güvenlik duvarını denetleyin ve 80 bağlantı noktasının açık olduğundan emin olun. Azure Ubuntu VM kullanıyorsanız, gelen bağlantı noktası 80 trafiğine izin veren bir ağ güvenlik grubu (NSG) kuralı ekleyin. Giden trafik, gelen kuralı etkinleştirildiğinde otomatik olarak verildiği için, giden bağlantı noktası 80 kuralını etkinleştirmeniz gerekmez.

Uygulamayı test tamamladıktan sonra komut isteminde CTRL + C ile uygulamayı kapatın.

Uygulamayı izleme

sunucu, üzerinde yapılan istekleri tarihinde http://<serveraddress>:80 üzerinde çalışan ASP.NET Core uygulamasına iletmek üzere ayarlanır Kestrel http://127.0.0.1:5000 . Ancak, NGINX işlemi yönetmek için ayarlanmadı Kestrel . systemd , temel Web uygulamasını başlatmak ve izlemek üzere bir hizmet dosyası oluşturmak için kullanılabilir. systemd , işlemlerin başlatılmasına, durdurulmasına ve yönetilmesine yönelik birçok güçlü özellik sağlayan bir init sistemidir.

Hizmet dosyasını oluşturma

Hizmet tanımı dosyasını oluşturun:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Aşağıdaki örnek, uygulama için bir hizmet dosyasıdır:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Yukarıdaki örnekte, hizmeti yöneten Kullanıcı User seçeneğiyle belirtilir. Kullanıcı ( www-data ) var olmalıdır ve uygulamanın dosyalarının doğru sahipliğini içermelidir.

TimeoutStopSecUygulamanın ilk kesme sinyali aldıktan sonra kapanması için bekleyeceği süreyi yapılandırmak için kullanın. Uygulama bu dönemde kapanmazsa, uygulamayı sonlandırmak için SIGKıLL çıkarılır. Değeri unitless saniyeler (örneğin, 150 ), bir zaman aralığı değeri (örneğin, 2min 30s ) veya infinity zaman aşımını devre dışı bırakmak için girin. TimeoutStopSec Varsayılan olarak, DefaultTimeoutStopSec yönetici yapılandırma dosyasında ( systemd-system.conf ,, system.conf.d systemd-user.conf , user.conf.d ) değerini alır. Çoğu dağıtım için varsayılan zaman aşımı 90 saniyedir.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux, büyük/küçük harfe duyarlı bir dosya sistemine sahiptir. ASPNETCORE_ENVIRONMENT Production Yapılandırma dosyası aranmasına neden olacak şekilde ayarlanıyor appsettings.Production.json appsettings.production.json .

yapılandırma sağlayıcılarının ortam değişkenlerini okuyabilmesi için bazı değerler (örneğin, SQL bağlantı dizeleri) kaçışmalıdır. Yapılandırma dosyasında kullanılmak üzere uygun bir kaçış değeri oluşturmak için aşağıdaki komutu kullanın:

systemd-escape "<value-to-escape>"

Environment=ConnectionStrings__DefaultConnection={Connection String}

Dosyayı kaydedin ve hizmeti etkinleştirin.

sudo systemctl enable kestrel-helloapp.service

Hizmeti başlatın ve çalıştığını doğrulayın.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Ters ara sunucu ile yapılandırılır ve Kestrel aracılığıyla yönetiliyorsa systemd , Web uygulaması tam olarak yapılandırılır ve konumundaki yerel makinedeki bir tarayıcıdan erişilebilir http://localhost . Ayrıca, uzak bir makineden de erişilebilir, engelleyici olabilecek tüm güvenlik duvarını açabilir. yanıt üst bilgilerini inceleyerek Server üst bilgi, tarafından sunulan ASP.NET Core uygulamayı gösterir Kestrel .

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Günlükleri görüntüleme

Kullanan Web uygulaması Kestrel tarafından yönetiliyor olduğundan systemd , tüm olaylar ve süreçler merkezi bir günlüğe kaydedilir. Ancak bu günlük, tarafından yönetilen tüm hizmetler ve süreçler için tüm girişleri içerir systemd . kestrel-helloapp.serviceBelirli öğeleri görüntülemek için aşağıdaki komutu kullanın:

sudo journalctl -fu kestrel-helloapp.service

Daha fazla filtreleme için,,, veya gibi zaman seçenekleri --since today --until 1 hour ago döndürülen girdi sayısını azaltabilir.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Veri koruma

ASP.NET Core veri koruma yığını , kimlik doğrulama ara yazılımı ( örneğin, cookie ara yazılım) ve siteler arası istek sahteciliğini önleme (csrf) korumaları dahil olmak üzere birkaç ASP.NET Core middlewares tarafından kullanılır. Veri koruma API 'Leri Kullanıcı kodu tarafından çağrılmasa bile, veri korumasının kalıcı bir şifreleme anahtarı deposuoluşturacak şekilde yapılandırılması gerekir. Veri koruması yapılandırılmamışsa, anahtarlar bellekte tutulur ve uygulama yeniden başlatıldığında atılır.

Uygulama yeniden başlatıldığında anahtar halkası bellekte depolanıyorsa:

• Tüm cookie tabanlı kimlik doğrulama belirteçleri geçersiz kılındı.
• Kullanıcıların bir sonraki isteğinde yeniden oturum açması gerekir.
• Anahtar halkası ile korunan tüm veriler artık çözülemez. bu, csrf belirteçlerini ve ASP.NET Core MVC tempdata cookie söğesini içerebilir.

Veri korumayı, anahtar halkasını sürdürmek ve şifrelemek üzere yapılandırmak için, bkz.:

• ASP.NET Core'de önemli depolama sağlayıcıları
• ASP.NET Core kullanarak Windows ve Azure'da bekleme ASP.NET Core

Uzun istek üst bilgisi alanları

Proxy sunucusu varsayılan ayarları, platforma bağlı olarak genellikle istek üst bilgisi alanlarını 4 K veya 8 K ile sınırlandırır. bir uygulama, varsayılan değerden daha uzun bir süre gerektirebilir (örneğin, Azure Active Directorykullanan uygulamalar). Daha uzun alanlar gerekliyse, proxy sunucusunun varsayılan ayarları ayarlama gerektirir. Uygulanacak değerler senaryoya göre değişir. Daha fazla bilgi için sunucunuzun belgelerine bakın.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Uygulamanın güvenliğini sağlama

AppArmor etkinleştir

Linux güvenlik modülleri (LSM), Linux 2,6 ' den beri Linux çekirdeğinin parçası olan bir çerçevedir. LSM, güvenlik modüllerinin farklı uygulamalarını destekler. AppArmor , programı sınırlı bir kaynak kümesiyle sınırlandırarak zorunlu bir Access Control sistemi uygulayan bir LSM 'dir. AppArmor etkinleştirildiğinden ve düzgün şekilde yapılandırıldığından emin olun.

Güvenlik duvarını yapılandırma

Kullanımda olmayan tüm dış bağlantı noktalarını kapatın. Karmaşık olmayan güvenlik duvarı (UW) iptables , güvenlik duvarını yapılandırmak için BIR CLI sağlayarak bir ön uç sağlar.

ufwGerekli olan herhangi bir bağlantı noktasında trafiğe izin vermek için bunu yükleyip yapılandırın.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Güvenli NGINX

NGINX yanıt adını değiştirme

Düzenle src/http/ngx_http_header_filter_module.c :

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Seçenekleri yapılandırma

Sunucuyu gerekli olan ek modüllerle yapılandırın. Uygulamayı sağlamlaştırmak için ModSecuritygibi bir Web uygulaması güvenlik duvarı kullanmayı düşünün.

HTTPS yapılandırması

Uygulamayı güvenli (HTTPS) yerel bağlantılar için yapılandırma

DotNet Run komutu, uygulamanın Özellikler tarafından belirtilen URL 'lerde dinlemek üzere uygulamayı yapılandıran dosya üzerinde uygulama özellikleri/launchSettings.js kullanır applicationUrl . Örneğin, https://localhost:5001;http://localhost:5000.

uygulamayı, dotnet run aşağıdaki yaklaşımlardan birini kullanarak komut veya geliştirme ortamı (f5 veya Ctrl + f5 Visual Studio Code) için geliştirme sürecinde bir sertifika kullanacak şekilde yapılandırın:

Güvenli (HTTPS) istemci bağlantıları için ters proxy 'yi yapılandırma

• Güvenilen bir sertifika yetkilisi (CA) tarafından verilen geçerli bir sertifika belirterek, sunucuyu 443 numaralı bağlantı noktasında HTTPS trafiğini dinleyecek şekilde yapılandırın.

• Aşağıdaki /etc/nginx/nginx.conf dosyasında gösterilen bazı uygulamalardan yararlanarak güvenliği en iyi şekilde yapın.

• Aşağıdaki örnek, sunucuyu güvenli olmayan istekleri yeniden yönlendirecek şekilde yapılandırmaz. HTTPS yeniden yönlendirme ara yazılımı kullanmanızı öneririz. Daha fazla bilgi için bkz. ASP.NET Core 'de HTTPS 'yi zorla.

  Not

  Sunucu yapılandırmasının HTTPS yeniden yönlendirme ara yazılımı yerine güvenli yönlendirmeyi işlediği geliştirme ortamları için kalıcı yeniden yönlendirmeler (301) yerine geçici yeniden yönlendirmeler (302) kullanmanızı öneririz. Bağlantıyı önbelleğe alma, geliştirme ortamlarında kararsız davranışa neden olabilir.

• Strict-Transport-Security(HSTS) üstbilgisi eklemek, istemci tarafından yapılan tüm sonraki ISTEKLERIN https üzerinden yapılmasını sağlar. Üstbilgiyi ayarlamaya yönelik yönergeler için Strict-Transport-Security bkz ASP.NET Core 'de HTTPS 'yi zorla ..

• Daha sonra HTTPS devre dışı bırakılabiliyorsanız, aşağıdaki yaklaşımlardan birini kullanın:

  • HSTS üst bilgisini eklemeyin.
  • Kısa bir max-age değer seçin.

/Etc/nginx/proxy.conf yapılandırma dosyasını ekleyin:

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

/etc/nginx/nginx.conf yapılandırma dosyasının içeriğini aşağıdaki dosyayla değiştirin. Örnek, bir yapılandırma http dosyasında hem hem de bölümlerini server içerir.

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Nginx'in tıklamadan güvenliğini sağlama

Kullanıcı arabirimi saldırı olarak da bilinen Tıklamak,web sitesi ziyaretçisi tarafından ziyaret edildiklerine göre farklı bir sayfada bulunan bir bağlantıya veya düğmeye tıklamak için kandırıldıklarına yönelik kötü amaçlı bir saldırıdır. Sitenin X-FRAME-OPTIONS güvenliğini sağlamak için kullanın.

Tıklama saldırılarını azaltmak için:

1. nginx.conf dosyasını düzenleyin:

   sudo nano /etc/nginx/nginx.conf
   

   Satırı ekleyin: add_header X-Frame-Options "SAMEORIGIN";

2. Dosyayı kaydedin.

3. Nginx'i yeniden başlatın.

MIME türü algılama

Üst bilgi tarayıcıya yanıt içerik türünü geçersiz kılmama talimatı verdiği için, bu üst bilgi çoğu tarayıcının bildirilen içerik türünden bir yanıtı MIME algılamasını önler. nosniffseçeneğiyle, sunucu içeriğin olduğunu söylüyorsa tarayıcı bunu olarak text/html text/html işler.

1. nginx.conf dosyasını düzenleyin:

   sudo nano /etc/nginx/nginx.conf
   

   Satırı ekleyin: add_header X-Content-Type-Options "nosniff";

2. Dosyayı kaydedin.

3. Nginx'i yeniden başlatın.

Ek Nginx önerileri

Sunucuda paylaşılan çerçeveyi yükselttikten sonra, sunucu tarafından ASP.NET Core uygulamaları yeniden başlatın.

Ek kaynaklar

• Linux'ta .NET Core önkoşulları
• Nginx: İkili Sürümler: Resmi Debian/Ubuntu paketleri
• ASP.NET Core projelerinde sorun giderme ve hata ayıklama
• Yapılandırma ASP.NET Core sunucuları ve yük dengeciler ile çalışacak şekilde yapılandırma
• NGINX: İ iletme üst bilgilerini kullanma