Aracılığıyla paylaş

Ters proxy ile arka uç web uygulaması arasında özgün HTTP ana bilgisayar adını koruma

Azure API Management
Azure App Service
Azure Application Gateway
Azure Front Door
Azure Spring Apps

Web uygulamasının önünde ters ara sunucu kullanırken özgün HTTP ana bilgisayar adını korumanızı öneririz. Ters proxy'de arka uç uygulama sunucusuna sağlanandan farklı bir ana bilgisayar adı olması, düzgün çalışmayan tanımlama bilgilerine veya yeniden yönlendirme URL'lerine yol açabilir. Örneğin oturum durumu kaybolabilir, kimlik doğrulaması başarısız olabilir veya arka uç URL'leri yanlışlıkla son kullanıcılara gösterilebilir. Uygulama sunucusunun web tarayıcısıyla aynı etki alanını görmesi için ilk isteğin ana bilgisayar adını koruyarak bu sorunları önleyebilirsiniz.

Bu kılavuz özellikle Azure App Service ve Azure Spring Apps gibi hizmet olarak platform (PaaS) tekliflerinde barındırılan uygulamalar için geçerlidir. Bu makalede, Azure Front DoorAzure Application Gatewayiçin ve yaygın olarak kullanılan ters ara sunucu hizmetleri olan Azure API Managementiçin belirli uygulama kılavuzu sağlanır.

Not

Web API'leri genellikle konak adı uyuşmazlıklarının neden olduğu sorunlara daha az duyarlıdır. Tek sayfalı bir uygulama ile arka uç API 'arasındaki iletişimin güvenliğini sağlamak için tanımlama bilgilerini kullanmadığınız sürece , örneğin ön uçlar için arka uçlarolarak bilinen bir düzende genellikle tanımlama bilgilerine bağımlı olmazlar. Web API'leri, Açık Veri Protokolü (OData) ve HATEOASgibi belirli API stilleri dışında genellikle mutlak URL'leri kendilerine geri döndürmez. API uygulamanız tanımlama bilgilerine bağımlıysa veya mutlak URL'ler oluşturuyorsa, bu makalede sağlanan yönergeler geçerlidir.

Uçtan uca TLS/SSL (ters proxy ile arka uç hizmeti arasındaki bağlantı HTTPS kullanır) gerekiyorsa, arka uç hizmetinin özgün ana bilgisayar adı için eşleşen bir TLS sertifikasına da ihtiyacı vardır. Bu gereksinim, sertifikaları dağıtıp yenilediğinizde işlem karmaşıklığını artırır, ancak birçok PaaS hizmeti tam olarak yönetilen ücretsiz TLS sertifikaları sunar.

Bağlam

HTTP isteğinin konağı

Çoğu durumda, istek işlem hattındaki uygulama sunucusu veya bazı bileşenler, tarayıcı tarafından erişilmesi için kullanılan internet etki alanı adına ihtiyaç duyar. Bu, isteğin ana bilgisayar. Bu bir IP adresi olabilir, ancak genellikle contoso.com gibi bir addır (tarayıcı daha sonra DNS kullanarak bir IP adresine çözümler). Konak değeri genellikle, tarayıcının HTTP üst bilgisiolarak uygulamaya gönderdiğiistek URI'sinin ana bilgisayar bileşeninden belirlenir.

Önemli

Hiçbir zaman bir güvenlik mekanizmasında konağın değerini kullanmayın. Değer tarayıcı veya başka bir kullanıcı aracısı tarafından sağlanır ve son kullanıcı tarafından kolayca değiştirilebilir.

Bazı senaryolarda, özellikle de istek zincirinde bir HTTP ters ara sunucusu olduğunda, özgün ana bilgisayar üst bilgisi uygulama sunucusuna ulaşmadan önce değiştirilebilir. Ters ara sunucu istemci ağ oturumunu kapatır ve arka uca yeni bir bağlantı ayarlar. Bu yeni oturumda, istemci oturumunun özgün ana bilgisayar adını taşıyabilir veya yeni bir tane ayarlayabilir. İkinci durumda, proxy genellikle özgün ana bilgisayar değerini Forwarded veya X-Forwarded-Hostgibi diğer HTTP üst bilgilerinde göndermeye devam eder. Bu değer, uygulamaların özgün ana bilgisayar adını belirlemesine olanak tanır, ancak yalnızca bu üst bilgileri okuyacak şekilde kodlanmışlarsa.

Web platformları neden ana bilgisayar adını kullanır?

Çok kiracılı PaaS hizmetleri, gelen bir isteği uygun kiracının arka uç sunucusuna yönlendirmek için genellikle kayıtlı ve doğrulanmış bir ana bilgisayar adı gerektirir. Bunun nedeni genellikle tüm kiracılar için gelen istekleri kabul eden paylaşılan bir yük dengeleyici havuzu olmasıdır. Kiracılar genellikle gelen ana bilgisayar adını kullanarak müşteri kiracısı için doğru arka ucu arar.

Bu platformlar, kullanmaya başlamayı kolaylaştırmak için genellikle trafiği dağıtılan örneğine yönlendirmek için önceden yapılandırılmış bir varsayılan etki alanı sağlar. App Service için bu varsayılan etki alanı azurewebsites.net. Oluşturduğunuz her web uygulaması kendi alt etki alanını (örneğin, contoso.azurewebsites.net) alır. Benzer şekilde, varsayılan etki alanı Azure Spring Apps için azuremicroservices.io ve API Management için azure-api.net'dir.

Üretim dağıtımları için bu varsayılan etki alanlarını kullanmazsınız. Bunun yerine, kuruluşunuzun veya uygulamanızın markasıyla uyumlu olması için kendi etki alanınızı sağlarsınız. Örneğin, contoso.com arka planda App Service'te contoso.azurewebsites.net web uygulamasına çözümlenebilir, ancak bu etki alanı web sitesini ziyaret eden son kullanıcı tarafından görülemez. Ancak platformun isteğe yanıt vermesi gereken arka uç sunucusunu tanımlayabilmesi için bu özel contoso.com ana bilgisayar adının PaaS hizmetine kaydedilmesi gerekir.

App Service'te konak tabanlı yönlendirmeyi gösteren Diyagramı.

Uygulamalar neden ana bilgisayar adını kullanır?

Bir uygulama sunucusunun ana bilgisayar adına ihtiyacı olmasının iki yaygın nedeni, mutlak URL'ler oluşturmak ve belirli bir etki alanı için tanımlama bilgileri vermektir. Örneğin, uygulama kodunun şunları yapması gerektiğinde:

  • HTTP yanıtında göreli URL yerine mutlak bir URL döndürür (ancak genellikle web siteleri mümkün olduğunda göreli bağlantıları işleme eğilimindedir).
  • Web sitesinin bağlantısını kullanıcıya e-postayla göndermek gibi göreli URL'lerin kullanılamadığı HTTP yanıtının dışında kullanılacak bir URL oluşturun.
  • Dış hizmet için mutlak bir yeniden yönlendirme URL'si oluşturun. Örneğin, başarılı bir kimlik doğrulamasından sonra kullanıcının nerede döndürülmesi gerektiğini belirtmek için Microsoft Entra ID gibi bir kimlik doğrulama hizmetine.
  • Tanımlama bilgisinin özniteliğinde tanımlandığı gibi, belirli bir ana bilgisayarla sınırlı HTTP tanımlama bilgileri verme.

Uygulamanın yapılandırmasına beklenen ana bilgisayar adını ekleyerek ve istekte gelen ana bilgisayar adı yerine statik olarak tanımlanan değeri kullanarak tüm bu gereksinimleri karşılayabilirsiniz. Ancak bu yaklaşım, uygulama geliştirme ve dağıtım konularını karmaşıklaştırır. Ayrıca, uygulamanın tek bir yüklemesi birden çok ana bilgisayara hizmet verebilir. Örneğin, tek bir web uygulaması, tümü kendi benzersiz ana bilgisayar adlarına (tenant1.contoso.com ve tenant2.contoso.comgibi) sahip olan birden çok uygulama kiracısı için kullanılabilir.

Bazen de gelen ana bilgisayar adı, uygulama kodunun dışındaki bileşenler veya üzerinde tam denetime sahip olmadığınız uygulama sunucusundaki ara yazılımda kullanılır. Aşağıda bazı örnekler verilmiştir:

  • App Service'te web uygulamanız için HTTPS zorlayabilirsiniz. Bunun yapılması güvenli olmayan http isteklerinin HTTPS'ye yeniden yönlendirilmesini sağlar. Bu durumda, gelen ana bilgisayar adı HTTP yeniden yönlendirmesinin Location üst bilgisinin mutlak URL'sini oluşturmak için kullanılır.
  • Azure Spring Apps, HTTPSzorlamak için benzer bir özellik kullanır. Ayrıca HTTPS URL'sini oluşturmak için gelen ana bilgisayarı kullanır.
  • App Service'te yapışkan oturumları etkinleştirmek için bir ARR benşimi ayarı vardır, böylece aynı tarayıcı örneğinden gelen istekler her zaman aynı arka uç sunucusu tarafından sunulur. Bu, HTTP yanıtına tanımlama bilgisi ekleyen App Service ön uçları tarafından gerçekleştirilir. Tanımlama bilgisinin Domain gelen ana bilgisayara ayarlanır.
  • App Service, kullanıcıların API'lerde kolayca oturum açmasına ve verilere erişmesine izin vermek için kimlik doğrulaması ve yetkilendirme özellikleri sağlar.
    • Gelen ana bilgisayar adı, kimlik sağlayıcısının başarılı kimlik doğrulamasından sonra kullanıcıyı döndürmesi gereken yeniden yönlendirme URL'sini oluşturmak için kullanılır.
    • Bu özelliğin varsayılan olarak etkinleştirilmesi,HTTP'den HTTPS'ye yeniden yönlendirmeyi de açar. Yeniden yönlendirme konumunu oluşturmak için gelen ana bilgisayar adı kullanılır.

Neden konak adını geçersiz kılmak isteyebilirsiniz?

App Service'te varsayılan etki alanı contoso.azurewebsites.netolan bir web uygulaması oluşturduğunuzu varsayalım. (Veya Azure Spring Apps gibi başka bir hizmette.) App Service'te özel bir etki alanı yapılandırmadınız. Application Gateway (veya benzer herhangi bir hizmet) gibi bir ters proxy'yi bu uygulamanın önüne koymak için, contoso.com için DNS kaydını Application Gateway'in IP adresine çözümleye ayarlayın. Bu nedenle, contoso.com isteğini tarayıcıdan alır ve bu isteği contoso.azurewebsites.net çözümlenen IP adresine iletecek şekilde yapılandırılır: bu, istenen ana bilgisayar için son arka uç hizmetidir. Ancak bu durumda App Service, contoso.com özel etki alanını tanımaz ve bu ana bilgisayar adı için gelen tüm istekleri reddeder. İsteğin nereye yönlendirileceğini belirleyemiyor.

Bu yapılandırmanın çalışmasını sağlamanın kolay yolu, Application Gateway'de HTTP isteğinin Host üst bilgisini geçersiz kılmak veya yeniden yazmak ve contoso.azurewebsites.netdeğerine ayarlamak gibi görünebilir. Bunu yaparsanız, Application Gateway'den gelen giden istek, özgün isteğin contoso.azurewebsites.netyerine gerçekten contoso.com için tasarlanmış gibi görünmesini sağlar:

Konak adı geçersiz kılınmış bir yapılandırmayı gösteren Diyagramı.

Bu noktada App Service konak adını tanır ve özel bir etki alanı adının yapılandırılmasını gerektirmeden isteği kabul eder. Aslında Application Gateway , arka uç havuzunun konağıyla konak üst bilgisi geçersiz kılmayı kolaylaştırır. Azure Front Door bunu varsayılan olarakbile yapar.

Ancak bu çözümle ilgili sorun, uygulama özgün ana bilgisayar adını görmediğinde çeşitli sorunlara yol açabilir.

Olası sorunlar

Yanlış mutlak URL'ler

Özgün ana bilgisayar adı korunmazsa ve uygulama sunucusu mutlak URL'ler oluşturmak için gelen ana bilgisayar adını kullanırsa, arka uç etki alanı son kullanıcıya açıklanabilir. Bu mutlak URL'ler uygulama kodu tarafından veya daha önce belirtildiği gibi App Service ve Azure Spring Apps'te HTTP'den HTTPS'ye yeniden yönlendirme desteği gibi platform özellikleriyle oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

Yanlış mutlak URL'ler sorununu gösteren Diyagramı.

  1. Tarayıcı ters ara sunucuya bir contoso.com isteği gönderir.
  2. Ters ara sunucu, arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) yönelik istekte contoso.azurewebsites.net için ana bilgisayar adını yeniden yazar.
  3. Uygulama, örneğin contoso.azurewebsites.netgelen https://contoso.azurewebsites.net/ ana bilgisayar adını temel alan bir mutlak URL oluşturur.
  4. Tarayıcı, contoso.comters ara sunucuya dönmek yerine doğrudan arka uç hizmetine giden bu URL'yi izler.

Bu durum, ters proxy'nin web uygulaması güvenlik duvarı olarak da görev yaptığı yaygın durumlarda güvenlik riski bile doğurabilir. Kullanıcı doğrudan arka uç uygulamasına giden ve ters ara sunucuyu atlayan bir URL alır.

Önemli

Bu güvenlik riski nedeniyle, arka uç web uygulamasının yalnızca ters proxy'den gelen ağ trafiğini doğrudan kabul ettiğinden emin olmanız gerekir (örneğin, App Service' de erişim kısıtlamalarını kullanarak). Bunu yaparsanız, yanlış bir mutlak URL oluşturulsa bile, en azından çalışmaz ve kötü amaçlı bir kullanıcı tarafından güvenlik duvarını atlamak için kullanılamaz.

Yanlış yeniden yönlendirme URL'leri

Mutlak yeniden yönlendirme URL'leri oluşturulduğunda önceki senaryoya ilişkin yaygın ve daha belirgin bir durum oluşur. Bu URL'ler OpenID Connect, Open Authorization (OAuth) 2.0 veya Security Assertion Markup Language (SAML) 2.0 gibi tarayıcı tabanlı kimlik protokollerini kullandığınızda Microsoft Entra ID gibi kimlik hizmetleri için gereklidir. Bu yeniden yönlendirme URL'leri, uygulama sunucusu veya ara yazılım tarafından veya daha önce belirtildiği gibi uygulama hizmeti kimlik doğrulaması ve yetkilendirme özelliklerigibi platform özellikleri tarafından oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

Yanlış yeniden yönlendirme URL'leri sorununu gösteren Diyagramı.

  1. Tarayıcı ters ara sunucuya bir contoso.com isteği gönderir.
  2. Ters ara sunucu, istekte arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) contoso.azurewebsites.net için ana bilgisayar adını yeniden yazar.
  3. Uygulama, örneğin contoso.azurewebsites.netgelen https://contoso.azurewebsites.net/ ana bilgisayar adını temel alan bir mutlak yeniden yönlendirme URL'si oluşturur.
  4. Tarayıcı, kullanıcının kimliğini doğrulamak için kimlik sağlayıcısına gider. İstek, başarılı kimlik doğrulamasından sonra kullanıcının döndürüleceği yeri belirtmek için oluşturulan yeniden yönlendirme URL'sini içerir.
  5. Kimlik sağlayıcıları genellikle yeniden yönlendirme URL'lerinin ön sırada kaydedilmesini gerektirir, bu nedenle bu noktada kimlik sağlayıcısının isteği reddetmesi gerekir çünkü sağlanan yeniden yönlendirme URL'si kaydedilmez. (Kullanılmaması gerekiyordu.) Ancak, bir nedenle yeniden yönlendirme URL'si kayıtlıysa, kimlik sağlayıcısı tarayıcıyı kimlik doğrulama isteğinde belirtilen yeniden yönlendirme URL'sine yönlendirir. Bu durumda URL https://contoso.azurewebsites.net/.
  6. Tarayıcı, ters ara sunucu yerine doğrudan arka uç hizmetine giden bu URL'yi izler.

Bozuk tanımlama bilgileri

Ana bilgisayar adı uyuşmazlığı, uygulama sunucusu tanımlama bilgileri verildiğinde ve tanımlama bilgisi özniteliğini oluşturmak için gelen ana bilgisayar adını kullandığında da sorunlara yol açabilir. Domain özniteliği, tanımlama bilgisinin yalnızca söz konusu etki alanı için kullanılmasını sağlar. Bu tanımlama bilgileri, uygulama kodu tarafından veya daha önce belirtildiği gibi uygulama hizmeti ARR benşim ayarıgibi platform özellikleri tarafından oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

Yanlış tanımlama bilgisi etki alanını gösteren Diyagramı.

  1. Tarayıcı ters ara sunucuya bir contoso.com isteği gönderir.
  2. Ters ara sunucu, arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) yapılan istekte contoso.azurewebsites.net konak adını yeniden yazar.
  3. Uygulama, gelen contoso.azurewebsites.net ana bilgisayar adını temel alan bir etki alanı kullanan bir tanımlama bilgisi oluşturur. Tarayıcı, kullanıcının gerçekten kullandığı contoso.com etki alanı yerine bu belirli etki alanı için tanımlama bilgisini depolar.
  4. Tanımlama bilgisinin contoso.com etki alanı isteğin etki alanıyla eşleşmediğinden tarayıcı sonraki contoso.azurewebsites.net isteğinde tanımlama bilgisini içermez. Uygulama daha önce yayımladığı tanımlama bilgisini almaz. Sonuç olarak, kullanıcı tanımlama bilgisinde olması gereken durumu kaybedebilir veya ARR benzimliği gibi özellikler çalışmaz. Ne yazık ki, bu sorunların hiçbiri hata oluşturmaz veya doğrudan son kullanıcı tarafından görülebilir. Bu, sorun gidermeyi zorlaştırıyor.

Yaygın Azure hizmetleri için uygulama kılavuzu

Burada ele alınan olası sorunları önlemek için, ters proxy ile arka uç uygulama sunucusu arasındaki çağrıda özgün ana bilgisayar adını korumanızı öneririz:

konak adının korunduğu bir yapılandırmayı gösteren Diyagramı.

Arka uç yapılandırması

Birçok web barındırma platformu, izin verilen gelen konak adlarını açıkça yapılandırmanızı gerektirir. Aşağıdaki bölümlerde, en yaygın Azure hizmetleri için bu yapılandırmanın nasıl uygulandığı açıklanmaktadır. Diğer platformlar genellikle özel etki alanlarını yapılandırmak için benzer yöntemler sağlar.

Web uygulamanızı App Service'de barındıracaksanız, web uygulaması özel bir etki alanı adı ekleyebilir ve arka uca doğru varsayılan ana bilgisayar adını kullanmaktan kaçınabilirsiniz. Web uygulamasına özel bir etki alanı eklerken DNS çözümlemenizi değiştirmeniz gerekmez: normal veya kayıtlarınızı etkilemeden kayıt kullanarak etki alanını doğrulayabilirsiniz. (Bu kayıtlar yine de ters proxy'nin IP adresine çözümleniyor.) Uçtan uca TLS/SSL gerekiyorsa, Key Vault'tan mevcut bir sertifikayı içeri aktarabilir veya özel etki alanınız için app service sertifikası kullanabilirsiniz. Bu durumda, etki alanının DNS kaydının ters proxy'ye değil doğrudan App Service'e çözümlenmesi gerektiğinden, ücretsiz App Service tarafından yönetilen sertifika kullanılamaz.

Benzer şekilde, Spring Appskullanıyorsanız, ana bilgisayar adını kullanmaktan kaçınmak için uygulama için özel bir etki alanı kullanabilirsiniz. Uçtan uca TLS/SSL gerekiyorsa mevcut veya otomatik olarak imzalanan bir sertifikayı içeri aktarabilirsiniz.

API Management (kendisi de ters ara sunucu işlevi görür) önünde ters ara sunucunuz varsa, ana bilgisayar adını kullanmaktan kaçınmak için API Management örneğinizde özel bir etki alanı yapılandırabilirsiniz. Uçtan uca TLS/SSL gerekiyorsa mevcut veya ücretsiz yönetilen sertifikayı içeri aktarabilirsiniz. Ancak daha önce belirtildiği gibi, API'ler konak adı uyuşmazlıklarının neden olduğu sorunlara daha az duyarlıdır, bu nedenle bu yapılandırma o kadar önemli olmayabilir.

Uygulamalarınızı Kubernetes veya doğrudan sanal makineler gibibaşka platformda barındırıyorsanız, gelen ana bilgisayar adına bağlı yerleşik bir işlev yoktur. Ana bilgisayar adının uygulama sunucusunun kendisinde nasıl kullanıldığından siz sorumlusunuz. Ana bilgisayar adını koruma önerisi, uygulamanızın ters proxy'leri özellikle tanımasını sağlamadığınız ve örneğin forwarded veya X-Forwarded-Host üst bilgilerine saygı duymadığınız sürece, uygulamanızda buna bağlı olan bileşenler için genellikle geçerlidir.

Ters proxy yapılandırması

Arka uçları ters ara sunucu içinde tanımladığınızda, arka uç hizmetinin varsayılan etki alanını (örneğin, https://contoso.azurewebsites.net/) kullanmaya devam edebilirsiniz. Bu URL, arka uç hizmetinin doğru IP adresini çözümlemek için ters ara sunucu tarafından kullanılır. Platformun varsayılan etki alanını kullanırsanız, IP adresinin her zaman doğru olduğu garanti edilir. Genellikle contoso.comgibi genel kullanıma yönelik etki alanını kullanamazsınız çünkü bunun ters proxy'nin IP adresine çözümlenmesi gerekir. (Split-horizon DNSgibi daha gelişmiş DNS çözümleme teknikleri kullanmadığınız sürece).

Önemli

Ters proxy ile son arka uç arasında Azure Güvenlik Duvarı Premium gibi yeni nesil bir güvenlik duvarınız varsa split-horizon DNS kullanmanız gerekebilir. Bu güvenlik duvarı türü, HTTP Host üst bilgisinin hedef IP adresine çözümlenip çözümlenmeyeceğini açıkça denetleyebilir. Böyle durumlarda, tarayıcı tarafından kullanılan özgün ana bilgisayar adı, genel İnternet'ten erişildiğinde ters proxy'nin IP adresine çözümlenmelidir. Ancak güvenlik duvarının bakış açısından bu ana bilgisayar adının son arka uç hizmetinin IP adresine çözümlenmesi gerekir. Daha fazla bilgi için bkz. Azure Güvenlik Duvarı ve Application Gatewayile web uygulamaları için sıfır güven ağı .

Çoğu ters proxy, arka uç hizmetine hangi ana bilgisayar adının geçirildiğini yapılandırmanıza olanak sağlar. Aşağıdaki bilgiler, en yaygın Azure hizmetleri için gelen isteğin özgün ana bilgisayar adının kullanılmasının nasıl sağlandığını açıklar.

Not

Her durumda, konak adını gelen istekten almak yerine açıkça tanımlanmış bir özel etki alanıyla geçersiz kılmayı da seçebilirsiniz. Uygulama yalnızca tek bir etki alanı kullanıyorsa, bu yaklaşım sorunsuz çalışabilir. Aynı uygulama dağıtımı birden çok etki alanından gelen istekleri kabul ederse (örneğin, çok kiracılı senaryolarda), tek bir etki alanını statik olarak tanımlayamazsınız. Gelen istekten ana bilgisayar adını almalısınız (uygulama ek HTTP üst bilgilerini hesaba katacak şekilde açıkça kodlanmadığı sürece). Bu nedenle genel öneri, konak adını hiç geçersiz kılmamanız gerektiğidir. Gelen ana bilgisayar adını değiştirilmemiş olarak arka uca geçirin.

Ters proxy'de konak adını korumanız veya geçersiz kılmanız fark etmeksizin , arka uç sunucusunun isteği sizin biçiminizde kabul etmek üzere yapılandırıldığından emin olun.

Application Gateway

Ters ara sunucu olarak Application Gateway kullanıyorsanız, arka uç HTTP ayarında yeni ana bilgisayar adı Geçersiz Kıl ayarını devre dışı bırakarak özgün ana bilgisayar adının korunmasını sağlayabilirsiniz. Bunu yaptığınızda hem arka uç adresinden konak adı seç hem de belirli etki alanı adıyla geçersiz kılma devre dışı bırakılır. (Bu ayarların her ikisi de konak adını geçersiz kılar.) Application Gatewayiçin Azure Resource Manager özelliklerinde bu yapılandırma, özelliğini ve olarak ayarlamaya karşılık gelir.

Sistem durumu yoklamaları gelen isteğin bağlamının dışına gönderildiğinden, doğru ana bilgisayar adını dinamik olarak belirleyemezler. Bunun yerine, özel bir sistem durumu yoklaması oluşturmanız, Arka uç HTTP ayarlarından ana bilgisayar adı seçindevre dışı bırakmanız ve ana bilgisayar adını açıkça belirtmeniz gerekir. Bu konak adı için tutarlılık için uygun bir özel etki alanı da kullanmalısınız. (Ancak, sistem durumu yoklamaları yanlış tanımlama bilgilerini yoksaydığından veya yanıttaki URL'leri yeniden yönlendirdiğinden burada barındırma platformunun varsayılan etki alanını kullanabilirsiniz.)

Azure Ön Kapı

Azure Front Doorkullanıyorsanız, kaynak tanımında kaynak ana bilgisayar üst bilgisini boş bırakarak konak adını koruyabilirsiniz. kaynakResource Manager tanımında, bu yapılandırma olarak ayarlanmasına karşılık gelir.

API Yönetimi

Varsayılan olarak, API Management, API'nin web hizmeti URL'sinin ana bilgisayar bileşeniyle arka uca gönderilen ana bilgisayar adını geçersiz kılar (API' nin Resource Manager tanımının değerine karşılık gelir).

Aşağıdaki gibi bir inboundÜst bilgi ayarla ilkesi ekleyerek API Management'ı gelen isteğin ana bilgisayar adını kullanmaya zorlayabilirsiniz:

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

Ancak daha önce belirtildiği gibi, API'ler konak adı uyuşmazlıklarının neden olduğu sorunlara daha az duyarlıdır, bu nedenle bu yapılandırma o kadar önemli olmayabilir.

Sonraki adımlar

  • app service
  • Spring Apps
  • Application Gateway
  • Azure Front Door
  • api management