مرجع دارایی میزبان مجازی

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

نمایش میزبان مجازی

شیء XML که برای تعریف یک میزبان مجازی استفاده می‌کنید، بر اساس نسخه Edge شما است: Cloud یا Private Cloud.

اگر شما مشتری Private Cloud هستید، باید مطمئن شوید که از XML صحیح برای نسخه Edge خود استفاده می‌کنید.

ابر و ابر خصوصی ۴.۱۷.۰۱ و بالاتر 

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <BaseUrl>http://myCo.com</BaseUrl>
    <OCSPStapling>offOn</OCSPStapling>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <!-- Private Cloud only -->
        <Interface>interfaceName</Interface>
    </Interfaces>
    <RetryOptions>
        <RetryOption>option</RetryOption>
    </RetryOptions>
    <ListenOptions>
        <ListenOption>option</ListenOption>
    </ListenOptions>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>ref://keystoreRef</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>ref://truststoreRef</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
    </SSLInfo>
    <!-- UseBuiltInFreeTrialCert is for Edge Cloud only -->
    <UseBuiltInFreeTrialCert>trueFalse</UseBuiltInFreeTrialCert>
    <PropagateTLSInformation>
        <!-- PropagateTLSInformation is Alpha in the Cloud only -->
        <ConnectionProperties>trueFalse</ConnectionProperties>
        <ClientProperties>trueFalse</ClientProperties>
    </PropagateTLSInformation>
    <Properties>
        <Property name="proxy_read_timeout">timeout</Property>
        <Property name="keepalive_timeout">timeout</Property>
        <Property name="proxy_request_buffering">onOff</Property>
        <Property name="proxy_buffering">onOff</Property>
        <!-- ssl_protocols is Private Cloud only -->
        <Property name="ssl_protocols">protocolList</Property>
        <Property name="ssl_ciphers">cipherList</Property>
    </Properties>
</VirtualHost>

ابر خصوصی ۴.۱۶.۰۱ تا ۴.۱۶.۰۹ 

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <Interface>interfaceName</Interface>
    </Interfaces>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>ref://keystoreRef</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>ref://truststoreRef</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

ابر خصوصی ۴.۱۵.۰۷ و قبل از آن 

<VirtualHost name="vhostName">
    <Port>portNumber</Port>
    <HostAliases>
        <HostAlias>hostAlias</HostAlias>
    </HostAliases>
    <Interfaces>
        <Interface>interfaceName</Interface>
    </Interfaces>
    <SSLInfo>
        <Enabled>trueFalse</Enabled>
        <ClientAuthEnabled>trueFalse</ClientAuthEnabled>
        <KeyStore>keystore</KeyStore>
        <KeyAlias>keyAlias</KeyAlias>
        <TrustStore>truststore</TrustStore>
        <IgnoreValidationErrors>trueFalse</IgnoreValidationErrors>
        <Ciphers>
             <Cipher>cipher</Cipher>
             <Cipher>cipher</Cipher>
         </Ciphers>
         <Protocols>
             <Protocol>protocol</Protocol>
             <Protocol>protocol</Protocol>
         </Protocols>
    </SSLInfo>
</VirtualHost>

ویژگی‌های پیکربندی میزبان مجازی

جدول زیر ویژگی‌هایی را که برای پیکربندی یک میزبان مجازی استفاده می‌کنید، فهرست می‌کند:

خواص توضیحات پیش‌فرض مورد نیاز
میزبان مجازی

نام میزبان مجازی را مشخص می‌کند. شما هنگام پیکربندی یک پروکسی API از آن نام برای ارجاع به میزبان مجازی استفاده می‌کنید.

کاراکترهایی که می‌توانید در ویژگی نام استفاده کنید به موارد زیر محدود می‌شوند: A-Z0-9._\-$%.

 هیچکدام بله
بندر

شماره پورت مورد استفاده توسط میزبان مجازی را مشخص می‌کند. مطمئن شوید که پورت روی روتر لبه (Edge Router) باز است.

اگر پورتی را در عنصر hostalias مشخص کنید، شماره پورت مشخص شده توسط <P ort> باید با آن مطابقت داشته باشد.

برای فضای ابری : هنگام ایجاد یک میزبان مجازی باید پورت ۴۴۳ را مشخص کنید. در صورت حذف، پورت به طور پیش‌فرض روی ۴۴۳ تنظیم می‌شود. اگر یک میزبان مجازی موجود دارید که از پورتی غیر از ۴۴۳ استفاده می‌کند، نمی‌توانید پورت را تغییر دهید.

برای نسخه‌های ۴.۱۶.۰۱ تا ۴.۱۷.۰۵ ابر خصوصی: هنگام ایجاد یک میزبان مجازی، پورت روتر مورد استفاده توسط میزبان مجازی را مشخص می‌کنید. به عنوان مثال، پورت ۹۰۰۱. به طور پیش‌فرض، روتر به عنوان کاربر "apigee" اجرا می‌شود که به پورت‌های ممتاز، معمولاً پورت‌های ۱۰۲۴ و پایین‌تر، دسترسی ندارد. اگر می‌خواهید یک میزبان مجازی ایجاد کنید که روتر را به یک پورت محافظت‌شده متصل کند، باید روتر را طوری پیکربندی کنید که به عنوان کاربری با دسترسی به آن پورت‌ها اجرا شود. برای اطلاعات بیشتر به بخش راه‌اندازی میزبان مجازی مراجعه کنید.

برای نسخه‌های ابر خصوصی قبل از ۴.۱۶.۰۱: یک روتر می‌تواند فقط به یک اتصال HTTPS به ازای هر میزبان مجازی، روی یک پورت خاص، با گواهی مشخص‌شده گوش دهد. بنابراین، اگر خاتمه TLS روی روتر در پورت مشخص‌شده رخ دهد، چندین میزبان مجازی نمی‌توانند از شماره پورت یکسان استفاده کنند.

 هیچکدام بله
آدرس پایه URL نمایش داده شده توسط رابط کاربری Edge را برای یک پروکسی API که در میزبان مجازی مستقر شده است، نادیده می‌گیرد. زمانی مفید است که یک متعادل‌کننده بار خارجی در مقابل روترهای Edge داشته باشید. برای اطلاعات بیشتر به پیکربندی دسترسی TLS به یک API برای ابر خصوصی مراجعه کنید.

مقدار BaseUrl باید شامل پروتکل باشد (یعنی "http://" یا "https://").

 هیچکدام خیر
منگنه‌زنی OCSP

یک کلاینت OCSP (پروتکل وضعیت گواهی آنلاین) یک درخواست وضعیت به یک پاسخ‌دهنده OCSP ارسال می‌کند تا مشخص شود که آیا گواهی TLS معتبر است یا خیر. پاسخ نشان می‌دهد که آیا گواهی TLS معتبر است و لغو نشده است.

وقتی فعال باشد، OCSP Stapling به Edge، که به عنوان سرور TLS برای TLS یک طرفه عمل می‌کند، اجازه می‌دهد تا مستقیماً از پاسخ‌دهنده OCSP پرس‌وجو کند و سپس پاسخ را ذخیره کند. سپس Edge این پاسخ را به کلاینت TLS برمی‌گرداند یا آن را به عنوان بخشی از TLS handshaking، Stapling می‌کند . برای اطلاعات بیشتر به فعال کردن OCSP Stapling روی سرور خود مراجعه کنید.

برای فعال کردن OCSP منگنه، TLS باید فعال باشد. برای فعال کردن، آن را on تنظیم کنید. مقدار پیش‌فرض off است.

 خاموش خیر
نام‌های مستعار میزبان
میزبان نام مستعار

نام DNS قابل مشاهده برای عموم میزبان مجازی روی روتر، که به صورت اختیاری شامل شماره پورت نیز می‌شود. ترکیب نام مستعار میزبان و شماره پورت برای میزبان مجازی باید برای همه میزبان‌های مجازی در نصب Edge منحصر به فرد باشد. این بدان معناست که چندین میزبان مجازی می‌توانند در صورت داشتن نام‌های مستعار میزبان متفاوت، از شماره پورت یکسانی استفاده کنند.

شما باید یک ورودی DNS و رکورد CNAME ایجاد کنید که با نام مستعار میزبان مطابقت داشته باشد، و نام مستعار میزبان باید با رشته‌ای که کلاینت در هدر Host ارسال می‌کند، مطابقت داشته باشد.

شماره پورت در HostAlias ​​اختیاری است. اگر پورت را به عنوان بخشی از نام مستعار میزبان مشخص کنید، باید همان پورت را با استفاده از عنصر <Port> نیز مشخص کنید. یا می‌توانید دو عنصر HostAlias ​​مشخص کنید، یکی با شماره پورت و دیگری بدون آن.

شما می‌توانید چندین تعریف HostAlias ​​را در یک تعریف میزبان مجازی داشته باشید، که مربوط به چندین ورودی DNS برای میزبان مجازی است، اما نه برای چندین پورت. اگر چندین پورت می‌خواهید، چندین تعریف میزبان مجازی با پورت‌های مختلف ایجاد کنید.

می‌توانید کاراکتر wildcard "*" را در نام مستعار میزبان قرار دهید. کاراکتر wildcard "*" فقط می‌تواند در ابتدا (قبل از اولین ".") نام مستعار میزبان باشد و نمی‌تواند با کاراکترهای دیگر مخلوط شود. به عنوان مثال *.example.com. گواهی TLS برای میزبان مجازی باید یک wildcard منطبق در نام CN گواهی داشته باشد. به عنوان مثال *.example.com . استفاده از wildcard در نام مستعار میزبان مجازی به پروکسی‌های API اجازه می‌دهد تا فراخوانی‌های آدرس‌دهی شده به چندین زیردامنه مانند alpha.example.com ، *.example.com یا live.example.com beta.example.com مدیریت کنند. استفاده از نام مستعار wildcard همچنین به شما کمک می‌کند تا از میزبان‌های مجازی کمتری در هر محیط استفاده کنید تا در محدوده محصول باقی بمانید، زیرا یک میزبان مجازی با wildcard تنها به عنوان یک میزبان مجازی محسوب می‌شود.

برای فضای ابری : اگر یک میزبان مجازی موجود دارید که از پورتی غیر از ۴۴۳ استفاده می‌کند، نمی‌توانید نام مستعار میزبان را اضافه یا حذف کنید.

برای ابر خصوصی: اگر نام مستعار میزبان را با استفاده از آدرس‌های IP روترهای خود و نه ورودی‌های DNS تنظیم می‌کنید، برای هر روتر یک نام مستعار میزبان جداگانه اضافه کنید که آدرس IP هر روتر و پورت میزبان مجازی را مشخص کند.

 هیچکدام بله
رابط‌ها فقط برای Edge برای فضای ابری خصوصی در دسترس است.
رابط

رابط‌های شبکه‌ای را که می‌خواهید port به آنها متصل شود، مشخص می‌کند. اگر این عنصر را حذف کنید، پورت به همه رابط‌ها متصل می‌شود.

برای مثال، برای مشخص کردن اینکه پورت فقط به en0 متصل شود:

<Interfaces>
  <Interface>en0</Interface>
</Interfaces>

با اجرای دستور "ifconfig -a" رابط‌های موجود در سیستم خود را تعیین کنید.

 هیچکدام همه رابط‌ها
گزینه‌های تلاش مجدد برای Edge Cloud و Private Cloud نسخه ۴.۱۸.۰۱ و بالاتر موجود است.
گزینه‌ی تلاش مجدد

نحوه واکنش روتر را برای این میزبان مجازی هنگام از کار افتادن پردازشگر پیام پیکربندی کنید.

شما می‌توانید با استفاده از <RetryOption> چندین مقدار را مشخص کنید. مقادیر معتبر عبارتند از:

off تلاش مجدد را غیرفعال می‌کند و میزبان مجازی در صورت درخواست، کد خطا را برمی‌گرداند.
http_599 (پیش‌فرض) اگر روتر یک پاسخ HTTP 599 از پردازنده پیام دریافت کند، درخواست را به پردازنده پیام بعدی ارسال می‌کند.

HTTP 599 یک کد پاسخ ویژه است که توسط یک پردازنده پیام هنگام خاموش شدن تولید می‌شود. پردازنده پیام سعی می‌کند تمام درخواست‌های موجود را تکمیل کند، اما برای هر درخواست جدید با HTTP 599 پاسخ می‌دهد تا به روتر سیگنال دهد که درخواست را در پردازنده پیام بعدی دوباره امتحان کند.

error اگر هنگام برقراری ارتباط با پردازشگر پیام، ارسال درخواست به آن یا خواندن هدر پاسخ از آن خطایی رخ دهد، روتر درخواست را به پردازشگر پیام بعدی ارسال می‌کند.
timeout اگر هنگام برقراری ارتباط با پردازشگر پیام، ارسال درخواست به آن یا خواندن هدر پاسخ از آن، وقفه زمانی رخ دهد، روتر درخواست را به پردازشگر پیام بعدی ارسال می‌کند.
invalid_header اگر پردازشگر پیام پاسخی خالی یا نامعتبر برگرداند، روتر درخواست را به پردازشگر پیام بعدی ارسال می‌کند.
http_ XXX اگر پردازنده پیام پاسخی با کد HTTP XXX برگرداند، روتر درخواست را به پردازنده پیام بعدی ارسال می‌کند.

اگر چندین مقدار را مشخص کنید، روتر از یک OR منطقی برای ترکیب آنها استفاده می‌کند.

برای مثال:

<RetryOptions>
  <RetryOption>http_599</RetryOption>
  <RetryOption>error</RetryOption>
  <RetryOption>timeout</RetryOption>
  <RetryOption>invalid_header</RetryOption>
</RetryOptions>
گزینه‌های گوش دادن برای Private Cloud 4.18.01 و بالاتر و برای Edge Cloud با ارسال درخواست به Apigee Edge Support در دسترس است.
گزینه گوش دادن

اگر از یک ELB در حالت TCP pass-thru برای مدیریت درخواست‌ها به روترهای لبه استفاده می‌کنید، روتر آدرس IP ELB را به عنوان IP کلاینت به جای IP واقعی کلاینت در نظر می‌گیرد. اگر روتر به IP کلاینت واقعی نیاز دارد، proxy_protocol روی ELB فعال کنید تا IP کلاینت را در بسته TCP ارسال کند. در روتر، باید <ListenOption> را روی میزبان مجازی روی proxy_protocol تنظیم کنید. از آنجا که ELB در حالت TCP pass-thru است، معمولاً TLS را روی روتر خاتمه می‌دهید. بنابراین، معمولاً میزبان مجازی را فقط زمانی که آن را برای استفاده از TLS پیکربندی می‌کنید، برای استفاده از proxy_protocol پیکربندی می‌کنید.

مقدار پیش‌فرض برای <ListenOption> یک رشته‌ی خالی است.

برای مثال:

<ListenOptions>
  <ListenOption>proxy_protocol</ListenOption>
</ListenOptions>

برای اینکه بعداً <ListenOption> غیرفعال کنید، میزبان مجازی را به‌روزرسانی کنید و برچسب <ListenOptions> را از به‌روزرسانی حذف کنید.

اطلاعات SSL
فعال شده

TLS/SSL یک طرفه را فعال می‌کند. شما باید یک keystore شامل گواهی و کلید خصوصی تعریف کرده باشید.

برای فضای ابری : شما باید یک گواهی امضا شده توسط یک نهاد معتبر مانند Symantec یا VeriSign داشته باشید. نمی‌توانید از یک گواهی خودامضا یا گواهی‌های Leaf که توسط یک CA خودامضا امضا شده‌اند استفاده کنید.

برای فضای ابری : اگر میزبان مجازی فعلی شما طوری پیکربندی شده باشد که از پورتی غیر از ۴۴۳ استفاده کند، نمی‌توانید تنظیمات TLS را تغییر دهید. این بدان معناست که نمی‌توانید تنظیمات TLS را از فعال به غیرفعال یا از غیرفعال به فعال تغییر دهید.

 نادرست خیر
ClientAuthEnabled TLS دوطرفه یا کلاینت را بین Edge (سرور) و برنامه (کلاینت) که درخواست را انجام می‌دهد، فعال می‌کند. فعال کردن TLS دوطرفه مستلزم آن است که شما یک truststore در Edge راه‌اندازی کنید که حاوی گواهی از کلاینت TLS باشد. نادرست خیر
فروشگاه کلید

نام فروشگاه کلید در Edge.

شرکت Apigee توصیه می‌کند که از یک مرجع برای مشخص کردن نام keystore استفاده کنید تا بتوانید keystore را بدون نیاز به راه‌اندازی مجدد روترها تغییر دهید. برای اطلاعات بیشتر به گزینه‌های پیکربندی TLS مراجعه کنید.

 هیچکدام بله اگر Enabled درست باشد
نام مستعار کلید نام مستعاری که هنگام آپلود گواهی و کلید خصوصی در keystore مشخص شده است. شما باید نام مستعار را به صورت تحت‌اللفظی مشخص کنید؛ نمی‌توانید از مرجع استفاده کنید. برای اطلاعات بیشتر به گزینه‌های پیکربندی TLS مراجعه کنید. هیچکدام بله اگر Enabled درست باشد
فروشگاه تراست

نام مرکز اعتماد در Edge که حاوی گواهی یا زنجیره گواهی مورد استفاده برای TLS دوطرفه است. در صورت صحیح بودن <ClientAuthEnabled> الزامی است.

شرکت Apigee توصیه می‌کند که از یک مرجع برای مشخص کردن نام truststore استفاده کنید تا بتوانید truststore را بدون نیاز به راه‌اندازی مجدد روترها تغییر دهید. برای اطلاعات بیشتر به گزینه‌های پیکربندی TLS مراجعه کنید.

 هیچکدام خیر
نادیده گرفتن خطاهای اعتبارسنجی

اگر مقدار آن درست باشد، مشخص می‌کند که خطاهای گواهی TLS نادیده گرفته شوند. این مشابه گزینه "-k" در cURL است.

این گزینه هنگام پیکربندی TLS برای سرورهای هدف و نقاط پایانی هدف و هنگام پیکربندی میزبان‌های مجازی که از TLS دوطرفه استفاده می‌کنند، معتبر است.

هنگام استفاده با یک نقطه پایانی/سرور هدف، اگر سیستم backend از SNI استفاده کند و گواهی با نام متمایز (DN) موضوعی که با نام میزبان مطابقت ندارد، برگرداند، هیچ راهی برای نادیده گرفتن خطا وجود ندارد و اتصال قطع می‌شود.

 نادرست خیر
رمزها

فقط برای Edge برای Private Cloud نسخه ۴.۱۵.۰۷ و قبل از آن.

رمزهای پشتیبانی شده توسط میزبان مجازی را مشخص می‌کند. اگر هیچ رمزی مشخص نشده باشد، تمام رمزهای موجود برای JVM مجاز خواهند بود.

برای محدود کردن رمزها، عناصر زیر را اضافه کنید:

<Ciphers>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
</Ciphers>
همه توسط JVM پشتیبانی می‌شوند خیر
پروتکل‌ها

فقط برای Edge برای Private Cloud نسخه ۴.۱۵.۰۷ و قبل از آن.

پروتکل‌های پشتیبانی شده توسط میزبان مجازی را مشخص می‌کند. اگر هیچ پروتکلی مشخص نشده باشد، تمام پروتکل‌های موجود برای JVM مجاز خواهند بود.

برای محدود کردن پروتکل‌ها، عناصر زیر را اضافه کنید:

<Protocols>
  <Protocol>TLSv1</Protocol>
  <Protocol>TLSv1.2</Protocol>
  <Protocol>SSLv2Hello</Protocol>
</Protocols>
همه توسط JVM پشتیبانی می‌شوند خیر
UseBuiltInFreeTrialCert فقط برای Edge Cloud موجود است.
UseBuiltInFreeTrialCert

اگر یک حساب کاربری پولی Edge for Cloud دارید و هنوز گواهی و کلید TLS ندارید، می‌توانید یک میزبان مجازی ایجاد کنید که از گواهی و کلید آزمایشی رایگان Apigee استفاده می‌کند. این بدان معناست که می‌توانید میزبان مجازی را بدون ایجاد اولیه یک فروشگاه کلید ایجاد کنید.

گواهی آزمایشی رایگان Apigee برای دامنه *.apigee.net تعریف شده است. بنابراین، <HostAlias> میزبان مجازی نیز باید به شکل *.apigee.net باشد.

به تعریف یک میزبان مجازی که از گواهی و کلید آزمایشی رایگان Apigee استفاده می‌کند، مراجعه کنید.

 نادرست خیر
اطلاعات TLS را منتشر کنید فقط برای Edge Cloud در نسخه آلفا موجود است.
ویژگی‌های اتصال

ثبت اطلاعات اتصال TLS توسط Edge را فعال می‌کند. این اطلاعات سپس به عنوان متغیرهای جریان در یک پروکسی API در دسترس هستند. برای اطلاعات بیشتر به دسترسی به اطلاعات اتصال TLS در یک پروکسی API مراجعه کنید.

 نادرست خیر
ویژگی‌های کلاینت

امکان دریافت جزئیات گواهی کلاینت که توسط Edge در TLS دوطرفه ثبت شده است را فراهم می‌کند. این اطلاعات سپس به عنوان متغیرهای جریان در یک پروکسی API در دسترس هستند. برای اطلاعات بیشتر به دسترسی به اطلاعات اتصال TLS در یک پروکسی API مراجعه کنید.

 نادرست خیر
خواص برای Edge Cloud و Private Cloud نسخه ۴.۱۷.۰۱ و بالاتر موجود است.
proxy_read_timeout

مدت زمان وقفه (timeout) بین پردازنده‌های پیام (Message Processors) و روتر (Router) را بر حسب ثانیه تنظیم می‌کند. اگر روتر قبل از انقضای این مدت زمان، پاسخی از پردازنده پیام دریافت نکند، اتصال را قطع کرده و پاسخ HTTP 504 را برمی‌گرداند.

مقدار proxy_read_timeout باید بیشتر از مقدار زمان انقضای هدف مورد استفاده توسط پردازنده پیام باشد. این تضمین می‌کند که روتر قبل از اینکه پردازنده پیام زمان کافی برای بازگرداندن پاسخ داشته باشد، زمان انقضا را دریافت نمی‌کند. زمان انقضای هدف پیش‌فرض برای پردازنده پیام ۵۵ ثانیه، ۵۵۰۰۰ میلی‌ثانیه است، همانطور که توسط توکن conf_http_HTTPTransport.io.timeout.millis برای پردازنده پیام تعریف شده است.

 ۵۷ خیر
keepalive_timeout

مدت زمان وقفه (timeout) بین کلاینت و روتر را بر حسب ثانیه تنظیم می‌کند، زمانی که کلاینت درخواستی حاوی هدر Keep-Alive ارسال می‌کند. روتر اتصال را تا زمان انقضای مدت زمان باز نگه می‌دارد.

اگر روتر در حال حاضر منتظر پاسخی از پردازنده پیام باشد، اتصال را قطع نمی‌کند. مهلت زمانی فقط پس از بازگشت پاسخ به کلاینت توسط روتر آغاز می‌شود.

 ۶۵ خیر
ssl_ciphers

رمزهای پشتیبانی شده توسط میزبان مجازی را تنظیم می‌کند و رمزهای پیش‌فرض تنظیم شده روی روتر را نادیده می‌گیرد.

لیستی از رمزها را که با علامت دونقطه از هم جدا شده‌اند، به شکل زیر مشخص کنید:

<Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;</Property>

برای اطلاعات بیشتر در مورد سینتکس و مقادیر مجاز توسط این توکن، به آدرس https://www.openssl.org/docs/man1.0.2/man1/ciphers.html مراجعه کنید. توجه داشته باشید که این توکن از نام‌های رمز OpenSSL مانند AES128-SHA256 استفاده می‌کند و نه از نام‌های رمز Java/JSSE مانند TLS_RSA_WITH_AES_128_CBC_SHA256.

 بالا:!aNULL:

!MD5:

!DH+3DES:

!kEDH

 خیر
پروتکل‌های ssl

فقط برای Edge برای فضای ابری خصوصی در دسترس است.

پروتکل‌های TLS پشتیبانی‌شده توسط میزبان مجازی را به صورت یک لیست با فاصله مشخص تنظیم می‌کند و پروتکل‌های پیش‌فرض تنظیم‌شده روی روتر را نادیده می‌گیرد.

نکته : اگر دو میزبان مجازی پورت یکسانی را به اشتراک بگذارند، باید ssl_protocols روی پروتکل‌های یکسان تنظیم کنند. به این معنی که میزبان‌های مجازی که پورت یکسانی را به اشتراک می‌گذارند، باید دقیقاً از پروتکل‌های یکسانی پشتیبانی کنند.

فهرستی از پروتکل‌های TLS را با فاصله از هم مشخص کنید، به شکل زیر: 

<Property name="ssl_protocols">TLSv1 TLSv1.2</Property>
 TLSv1 TLSv1.1 TLSv1.2 خیر
proxy_request_buffering

فعال (روشن) یا غیرفعال (خاموش) کردن بافر کردن بدنه درخواست. وقتی بافر کردن روشن است، روتر قبل از ارسال کل بدنه درخواست به پردازنده پیام، آن را بافر می‌کند. در صورت وجود خطا، روتر می‌تواند یک پردازنده پیام دیگر را دوباره امتحان کند.

اگر خاموش باشد، بافرینگ غیرفعال می‌شود و بدنه درخواست بلافاصله پس از دریافت به پردازشگر پیام ارسال می‌شود. اگر خطایی وجود داشته باشد، روتر درخواست را به پردازشگر پیام دیگری دوباره امتحان نمی‌کند.

 روی خیر
proxy_buffering فعال (روشن) یا غیرفعال (خاموش) کردن بافر پاسخ. وقتی بافر روشن است، روتر پاسخ را بافر می‌کند. وقتی بافر خاموش است، پاسخ بلافاصله پس از دریافت توسط روتر، به صورت همزمان به کلاینت ارسال می‌شود. روی خیر