پیکربندی کامل سرور

این صفحه مستندات مربوط به تمام فیلدهای فایل پیکربندی سرور را ارائه می‌دهد.

توجه: یکی از الگوهای رایجی که در پیکربندی کلاینت و سرور با آن مواجه خواهید شد، «انتخابگر نوع» است:

example:
  type: a
  a:
    something: something
  b:
    something: something
  c:
    something: something

type تعیین می‌کند که کدام حالت استفاده شود و کدام زیرفیلدها تجزیه شوند. در این مثال، فیلد example می‌تواند a، b یا c باشد. اگر a انتخاب شود، زیرفیلد a تجزیه شده و زیرفیلدهای b و c نادیده گرفته می‌شوند.

Listen

فیلد listen آدرس گوش‌دادن سرور است. اگر حذف شود، سرور روی :443 گوش می‌دهد زیرا این پورت پیش‌فرض HTTP/3 است.

listen: :443 # (1)!

1. وقتی آدرس IP حذف شود، سرور روی تمام رابط‌ها، هم IPv4 و هم IPv6، گوش می‌دهد. برای گوش‌دادن فقط روی IPv4، می‌توانید از 0.0.0.0:443 استفاده کنید. برای گوش‌دادن فقط روی IPv6، می‌توانید از [::]:443 استفاده کنید.

TLS

می‌توانید از tls یا acme استفاده کنید، اما نه هر دو به طور همزمان.

tls: # (1)!
  cert: some.crt
  key: some.key
  sniGuard: strict | disable | dns-san # (2)!
  clientCA: client.crt # (3)!

acme:
  domains:
    - domain1.com
    - domain2.org
  email: [email protected]
  ca: zerossl # (1)!
  listenHost: 0.0.0.0 # (2)!
  dir: my_acme_dir # (3)!
  type: http | tls | dns # (4)!
  http:
    altPort: 8888 # (5)!
  tls:
    altPort: 44333 # (6)!
  dns:
    name: gomommy # (7)!
    config:
      key1: value1
      key2: value2

مبهم‌سازی

به طور پیش‌فرض، پروتکل Hysteria خود را به عنوان HTTP/3 جا می‌زند. اگر شبکه شما به طور خاص ترافیک QUIC یا HTTP/3 را مسدود می‌کند (اما نه UDP به طور کلی)، می‌توان از مبهم‌سازی برای دور زدن این مشکل استفاده کرد. ما در حال حاضر یک پیاده‌سازی مبهم‌سازی به نام «Salamander» داریم که بسته‌ها را به بایت‌های به ظاهر تصادفی و بدون الگو تبدیل می‌کند. این قابلیت نیاز به رمز عبوری دارد که باید در هر دو سمت کلاینت و سرور یکسان باشد.

توجه: فعال‌سازی مبهم‌سازی سرور شما را با اتصالات استاندارد QUIC ناسازگار کرده و دیگر به عنوان یک سرور معتبر HTTP/3 عمل نخواهد کرد.

obfs:
  type: salamander # (2)!
  salamander:
    password: cry_me_a_r1ver # (1)!

1. با یک رمز عبور قوی به انتخاب خود جایگزین کنید.
2. لطفاً دستورالعمل‌های مربوط به «انتخابگر نوع» در بالای این صفحه را بخوانید.

پارامترهای QUIC

quic:
  initStreamReceiveWindow: 8388608 # (1)!
  maxStreamReceiveWindow: 8388608 # (2)!
  initConnReceiveWindow: 20971520 # (3)!
  maxConnReceiveWindow: 20971520 # (4)!
  maxIdleTimeout: 30s # (5)!
  maxIncomingStreams: 1024 # (6)!
  disablePathMTUDiscovery: false # (7)!

1. اندازه اولیه پنجره دریافت جریان QUIC.
2. حداکثر اندازه پنجره دریافت جریان QUIC.
3. اندازه اولیه پنجره دریافت اتصال QUIC.
4. حداکثر اندازه پنجره دریافت اتصال QUIC.
5. حداکثر مهلت بیکاری. مدت زمانی که سرور کلاینت را بدون هیچ فعالیتی همچنان متصل تلقی می‌کند.
6. حداکثر تعداد جریان‌های ورودی همزمان.
7. غیرفعال‌سازی کشف MTU مسیر QUIC.

اندازه‌های پیش‌فرض پنجره دریافت جریان و اتصال به ترتیب ۸ مگابایت و ۲۰ مگابایت هستند. ما تغییر این مقادیر را توصیه نمی‌کنیم مگر اینکه کاملاً بدانید چه کار می‌کنید. اگر تصمیم به تغییر این مقادیر گرفتید، توصیه می‌کنیم نسبت پنجره دریافت جریان به پنجره دریافت اتصال را ۲:۵ نگه دارید.

پهنای باند

bandwidth:
  up: 1 gbps
  down: 1 gbps

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

واحدهای پشتیبانی‌شده:

• bps یا b (بیت در ثانیه)
• kbps یا kb یا k (کیلوبیت در ثانیه)
• mbps یا mb یا m (مگابیت در ثانیه)
• gbps یا gb یا g (گیگابیت در ثانیه)
• tbps یا tb یا t (ترابیت در ثانیه)

نادیده گرفتن پهنای باند کلاینت

ignoreClientBandwidth: false

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

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

فرآیند مذاکره پهنای باند

نمودار زیر فرآیند مذاکره الگوریتم کنترل ازدحام و مقدار پهنای باند بین کلاینت و سرور تحت پیکربندی‌های مختلف را نشان می‌دهد.

graph TD;
    ICB{{"آیا سرور با ignoreClientBandwidth: true پیکربندی شده است؟"}} -- "بله" --> BBR[/"استفاده از BBR"/];
    ICB -- "خیر" --> C_has_BW;
    C_has_BW{{"آیا کلاینت با bandwidth پیکربندی شده است؟"}} -- "خیر" --> BBR;
    C_has_BW -- "بله" --> Brutal;
    Brutal["استفاده از Brutal"] --> S_has_BW;
    S_has_BW{{"آیا سرور با bandwidth پیکربندی شده است؟"}} -- "خیر" --> Brutal_C[/"استفاده از مقدار کلاینت"/];
    S_has_BW -- "بله" --> S_C_CMP;
    S_C_CMP{{"مقایسه مقادیر bandwidth سرور و کلاینت"}} -- "سرور بیشتر" --> Brutal_C;
    S_C_CMP -- "کلاینت بیشتر" --> Brutal_S[/"استفاده از مقدار سرور"/];

    style BBR fill:#dc322f;
    style Brutal fill:#268bd2;
    style Brutal_C fill:#2aa198;
    style Brutal_S fill:#2aa198;

اگر سرور Hysteria را برای استفاده شخصی راه‌اندازی می‌کنید، می‌توانید با حذف bandwidth و ignoreClientBandwidth از پیکربندی سرور و تعیین پهنای باند فقط در پیکربندی کلاینت، کار را ساده‌تر کنید:

graph TD;
    S_no_BW["`مطمئن شوید که سرور با bandwidth و ignoreClientBandwidth پیکربندی **نشده** است`"] --> C_has_BW;
    C_has_BW{{"آیا کلاینت با bandwidth پیکربندی شده است؟"}} -- "خیر" --> BBR[/"BBR"/];
    C_has_BW -- "بله" --> Brutal_C[/"استفاده از Brutal با مقدار کلاینت"/];

    style BBR fill:#dc322f;
    style Brutal_C fill:#2aa198;

جزئیات کنترل ازدحام

(اطلاعات این بخش جزئیات پیاده‌سازی داخلی Hysteria محسوب می‌شوند و ممکن است بین نسخه‌ها تغییر کنند)

در حال حاضر Hysteria دارای ۲ الگوریتم کنترل ازدحام است:

BBR: این الگوریتم در ابتدا توسط Google برای TCP توسعه یافت و ما آن را با تغییرات جزئی برای QUIC سازگار کردیم. BBR یک الگوریتم کنترل ازدحام معمول است که شامل مراحل شروع آهسته و تخمین پهنای باند بر اساس تغییرات RTT می‌شود. به تنهایی کار می‌کند و نیاز به تنظیمات پهنای باند ندارد.

Brutal: این الگوریتم کنترل ازدحام سفارشی Hysteria است. برخلاف BBR، الگوریتم Brutal بر مبنای مدل نرخ ثابت کار می‌کند و سرعت خود را در پاسخ به از دست رفتن بسته یا تغییرات RTT کاهش نمی‌دهد. اگر نتواند به نرخ هدف از پیش تعیین‌شده برسد، الگوریتم نرخ از دست رفتن بسته را محاسبه کرده و با افزایش سرعت جبران می‌کند. این فقط در صورتی کار می‌کند که حداکثر سرعت نظری اتصال فعلی خود را بدانید (و دقیقاً مشخص کنید). این الگوریتم به ویژه در تصاحب پهنای باند در شبکه‌های شلوغ با تحویل حداکثر تلاش مؤثر است، و از همین رو نام‌گذاری شده است.

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

الگوریتم‌های کنترل ازدحام ارسال داده را کنترل می‌کنند. از دیدگاه کلاینت، اگر کاربر مقدار پهنای باند خود را برای دانلود ارائه ندهد (اما برای آپلود ارائه دهد)، سرور Hysteria داده‌ها را با استفاده از BBR به کلاینت ارسال خواهد کرد، اما کلاینت داده‌ها را با استفاده از Brutal به سرور آپلود خواهد کرد، و بالعکس. کلاینت می‌تواند هر دو مقدار را ارائه دهد تا هر دو جهت از Brutal استفاده کنند، یا هیچ‌کدام را ارائه ندهد تا هر دو از BBR استفاده کنند.

حالت خاص، همان‌طور که در بالا ذکر شد، زمانی است که سرور ignoreClientBandwidth را فعال کرده باشد. در این حالت هر دو طرف همیشه از BBR استفاده خواهند کرد، صرف‌نظر از مقادیر پهنای باند کلاینت.

محدودیت پهنای باند سرور در حال حاضر فقط برای Brutal اعمال می‌شود. هیچ تأثیری بر BBR ندارد.

تست سرعت

speedTest: false

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

UDP

disableUDP: false

disableUDP ارسال UDP را غیرفعال می‌کند و فقط اتصالات TCP را مجاز می‌سازد.

udpIdleTimeout: 60s

udpIdleTimeout مدت زمانی را مشخص می‌کند که سرور پورت محلی UDP را برای هر نشست UDP بدون فعالیت باز نگه می‌دارد. این از نظر مفهومی مشابه مهلت نشست UDP در NAT است.

احراز هویت

auth:
  type: password | userpass | http | command # (6)!
  password: your_password # (1)!
  userpass: # (2)!
    user1: pass1
    user2: pass2
    user3: pass3
  http:
    url: http://your.backend.com/auth # (3)!
    insecure: false # (4)!
  command: /etc/some_command # (5)!

1. با یک رمز عبور قوی به انتخاب خود جایگزین کنید.
2. نگاشتی از جفت‌های نام‌کاربری-رمز عبور.
3. آدرس URL سرور بک‌اند که احراز هویت را مدیریت می‌کند.
4. غیرفعال‌سازی تأیید TLS برای سرور بک‌اند (فقط برای URLهای HTTPS اعمال می‌شود).
5. مسیر دستوری که احراز هویت را مدیریت می‌کند.
6. لطفاً دستورالعمل‌های مربوط به «انتخابگر نوع» در بالای این صفحه را بخوانید.

احراز هویت HTTP

هنگام استفاده از احراز هویت HTTP، سرور هنگام تلاش کلاینت برای اتصال، یک درخواست POST با بدنه JSON زیر به سرور بک‌اند ارسال می‌کند:

{
  "addr": "123.123.123.123:44556", // (1)!
  "auth": "something_something", // (2)!
  "tx": 123456 // (3)!
}

1. آدرس IP و پورت کلاینت.
2. داده‌های احراز هویت کلاینت.
3. نرخ ارسال (tx) (بر حسب بایت در ثانیه). tx از دیدگاه سرور؛ مطابق با نرخ دریافت (دانلود) کلاینت است.

نقطه پایانی شما باید با یک شیء JSON با فیلدهای زیر پاسخ دهد:

{
  "ok": true, // (1)!
  "id": "john_doe" // (2)!
}

1. آیا اجازه اتصال به این کلاینت داده شود.
2. شناسه یکتای کلاینت. این در لاگ‌ها و API آمار ترافیک استفاده می‌شود.

توجه: کد وضعیت HTTP باید ۲۰۰ باشد تا احراز هویت موفق تلقی شود.

احراز هویت با دستور

هنگام استفاده از احراز هویت با دستور، سرور هنگام تلاش کلاینت برای اتصال، دستور مشخص‌شده را با آرگومان‌های زیر اجرا می‌کند:

/etc/some_command addr auth tx # (1)!

1. تعریف هر آرگومان مانند بخش احراز هویت HTTP در بالا است.

دستور باید شناسه یکتای کلاینت را به stdout چاپ کند و در صورت مجاز بودن اتصال کلاینت با کد خروج ۰، یا در صورت رد کلاینت با کد خروج غیرصفر بازگردد.

اگر دستور قابل اجرا نباشد، کلاینت رد خواهد شد.

حل‌کننده نام

می‌توانید مشخص کنید که از کدام حل‌کننده (سرور DNS) برای ترجمه نام‌های دامنه در درخواست‌های کلاینت استفاده شود.

resolver:
  type: udp | tcp | tls | https # (8)!
  tcp:
    addr: 8.8.8.8:53 # (1)!
    timeout: 4s # (2)!
  udp:
    addr: 8.8.4.4:53 # (3)!
    timeout: 4s
  tls:
    addr: 1.1.1.1:853 # (4)!
    timeout: 10s
    sni: cloudflare-dns.com # (5)!
    insecure: false # (6)!
  https:
    addr: 1.1.1.1:443 # (7)!
    timeout: 10s
    sni: cloudflare-dns.com
    insecure: false

1. آدرس حل‌کننده TCP.
2. مهلت زمانی پرس‌وجوهای DNS.
3. آدرس حل‌کننده UDP.
4. آدرس حل‌کننده TLS.
5. SNI برای حل‌کننده TLS.
6. غیرفعال‌سازی تأیید TLS برای حل‌کننده TLS.
7. آدرس حل‌کننده HTTPS.
8. لطفاً دستورالعمل‌های مربوط به «انتخابگر نوع» در بالای این صفحه را بخوانید.

اگر حذف شود، Hysteria از حل‌کننده پیش‌فرض سیستم استفاده خواهد کرد.

شناسایی پروتکل

به دلیل عواملی مانند ورودی کلاینت (مثلاً حالت TUN) و پیکربندی، Hysteria گاهی نمی‌تواند نام دامنه آدرس مقصد را دریافت کند و فقط IP را می‌گیرد. اما IPای که کلاینت و سرور برای یک دامنه دریافت می‌کنند ممکن است متفاوت باشد، و قوانین دامنه ACL نمی‌توانند درخواست‌های IP را مطابقت دهند. با فعال‌سازی شناسایی پروتکل، سرور می‌تواند از DPI برای استخراج نام دامنه از اتصال (برای پروتکل‌های پشتیبانی‌شده) استفاده کرده و درخواست IP را به درخواست دامنه تبدیل کند.

پروتکل‌های پشتیبانی‌شده فعلی:

• HTTP — Host در هدر
• TLS (HTTPS) — SNI
• QUIC (HTTP/3) — SNI

sniff:
  enable: true # (1)!
  timeout: 2s # (2)!
  rewriteDomain: false # (3)!
  tcpPorts: 80,443,8000-9000 # (4)!
  udpPorts: all # (5)!

1. فعال‌سازی شناسایی پروتکل.
2. مهلت زمانی شناسایی. اگر پروتکل/دامنه در این مدت قابل تعیین نباشد، از آدرس اصلی برای برقراری اتصال استفاده می‌شود.
3. بازنویسی درخواست‌هایی که قبلاً به صورت نام دامنه هستند. اگر فعال باشد، درخواست‌هایی که آدرس مقصد آن‌ها قبلاً به صورت نام دامنه است نیز شناسایی خواهند شد.
4. لیست پورت‌های TCP. فقط درخواست‌های TCP روی این پورت‌ها شناسایی می‌شوند.
5. لیست پورت‌های UDP. فقط درخواست‌های UDP روی این پورت‌ها شناسایی می‌شوند.

توجه: اگر لیست پورت ارائه نشود، به طور پیش‌فرض تمام پورت‌ها شناسایی می‌شوند. فرمت لیست پورت مشابه جابجایی پورت است و از پورت‌های منفرد متعدد و بازه‌های پورت (شامل) جدا شده با کاما پشتیبانی می‌کند.

ACL

ACL که اغلب همراه با خروجی‌ها استفاده می‌شود، قابلیت بسیار قدرتمندی در سرور Hysteria است که به شما اجازه می‌دهد نحوه مدیریت درخواست‌های کلاینت را سفارشی کنید. به عنوان مثال، می‌توانید از ACL برای مسدود کردن آدرس‌های خاص، یا استفاده از خروجی‌های مختلف برای وب‌سایت‌های مختلف استفاده کنید.

برای جزئیات مربوط به نحو، استفاده و اطلاعات دیگر، لطفاً به مستندات ACL مراجعه کنید.

می‌توانید از file یا inline استفاده کنید، اما نه هر دو.

acl:
  file: some.txt # (1)!
  # geoip: geoip.dat (2)
  # geosite: geosite.dat (3)
  # geoUpdateInterval: 168h (4)

acl:
  inline: # (1)!
    - reject(suffix:v2ex.com)
    - reject(all, udp/443)
    - reject(geoip:cn)
    - reject(geosite:netflix)
  # geoip: geoip.dat (2)
  # geosite: geosite.dat (3)
  # geoUpdateInterval: 168h (4)

توجه: Hysteria در حال حاضر از فرمت «dat» مبتنی بر protobuf برای داده‌های geoip/geosite که از v2ray منشأ گرفته‌اند استفاده می‌کند. اگر نیازی به سفارشی‌سازی ندارید، می‌توانید فیلدهای geoip یا geosite را حذف کنید و اجازه دهید Hysteria به طور خودکار آخرین نسخه را (از https://github.com/Loyalsoldier/v2ray-rules-dat) در دایرکتوری کاری شما دانلود کند. فایل‌ها فقط در صورتی دانلود و استفاده می‌شوند که ACL شما حداقل یک قانون داشته باشد که از این قابلیت استفاده کند.

توجه: Hysteria در حال حاضر پایگاه‌های داده GeoIP/GeoSite را فقط یک بار هنگام راه‌اندازی دانلود می‌کند. برای به‌روزرسانی منظم پایگاه‌های داده از طریق geoUpdateInterval باید از ابزارهای خارجی برای ری‌استارت دوره‌ای سرور Hysteria استفاده کنید. این ممکن است در نسخه‌های آینده تغییر کند.

خروجی‌ها

خروجی‌ها برای تعریف «خروجگاه» مورد استفاده قرار می‌گیرند که اتصال باید از طریق آن مسیریابی شود. به عنوان مثال، هنگام استفاده همراه با ACL، می‌توانید تمام ترافیک به جز Netflix را مستقیماً از طریق رابط محلی مسیریابی کنید، در حالی که ترافیک Netflix را از طریق پراکسی SOCKS5 هدایت کنید.

در حال حاضر Hysteria از انواع خروجی زیر پشتیبانی می‌کند:

• direct: اتصال مستقیم از طریق رابط محلی.
• socks5: پراکسی SOCKS5.
• http: پراکسی HTTP/HTTPS.

توجه: پراکسی‌های HTTP/HTTPS در سطح پروتکل از UDP پشتیبانی نمی‌کنند. ارسال ترافیک UDP به خروجی‌های HTTP منجر به رد شدن خواهد شد.

اگر از ACL استفاده نمی‌کنید، تمام اتصالات همیشه از طریق اولین («پیش‌فرض») خروجی در لیست مسیریابی می‌شوند و تمام خروجی‌های دیگر نادیده گرفته می‌شوند.

outbounds:
  - name: my_outbound_1 # (1)!
    type: direct # (7)!
  - name: my_outbound_2
    type: socks5
    socks5:
      addr: shady.proxy.ru:1080 # (2)!
      username: hackerman # (3)!
      password: Elliot Alderson # (4)!
  - name: my_outbound_3
    type: http
    http:
      url: http://username:[email protected]:8081 # (5)!
      insecure: false # (6)!

1. نام خروجی. در قوانین ACL استفاده می‌شود.
2. آدرس پراکسی SOCKS5.
3. اختیاری. نام‌کاربری برای پراکسی SOCKS5، در صورت نیاز به احراز هویت.
4. اختیاری. رمز عبور برای پراکسی SOCKS5، در صورت نیاز به احراز هویت.
5. آدرس URL پراکسی HTTP/HTTPS. (می‌تواند http:// یا https:// باشد)
6. اختیاری. غیرفعال‌سازی تأیید TLS. فقط برای پراکسی‌های HTTPS اعمال می‌شود.
7. لطفاً دستورالعمل‌های مربوط به «انتخابگر نوع» در بالای این صفحه را بخوانید.

سفارشی‌سازی خروجی direct

خروجی direct چند گزینه اضافی برای سفارشی‌سازی رفتار خود دارد:

توجه: گزینه‌های bindIPv4، bindIPv6 و bindDevice ناسازگار هستند. می‌توانید bindIPv4 و/یا bindIPv6 را بدون bindDevice مشخص کنید، یا از bindDevice بدون bindIPv4 و bindIPv6 استفاده کنید.

outbounds:
  - name: hoho
    type: direct
    direct:
      mode: auto # (1)!
      bindIPv4: 2.4.6.8 # (2)!
      bindIPv6: 0:0:0:0:0:ffff:0204:0608 # (3)!
      bindDevice: eth233 # (4)!
      fastOpen: false # (5)!

1. توضیحات زیر را ببینید.
2. آدرس IPv4 محلی برای اتصال.
3. آدرس IPv6 محلی برای اتصال.
4. رابط شبکه محلی برای اتصال.
5. فعال‌سازی TCP Fast Open.

مقادیر mode موجود:

• auto: پیش‌فرض. حالت دوگانه «happy eyeballs». کلاینت تلاش می‌کند با استفاده از هر دو آدرس IPv4 و IPv6 (در صورت موجود بودن) به مقصد متصل شود و از اولین آدرسی که موفق شود استفاده می‌کند.
• 64: همیشه از IPv6 استفاده کن اگر موجود باشد، در غیر این صورت IPv4.
• 46: همیشه از IPv4 استفاده کن اگر موجود باشد، در غیر این صورت IPv6.
• 6: همیشه از IPv6 استفاده کن. در صورت عدم موجود بودن IPv6 خطا می‌دهد.
• 4: همیشه از IPv4 استفاده کن. در صورت عدم موجود بودن IPv4 خطا می‌دهد.

API آمار ترافیک (HTTP)

API آمار ترافیک به شما امکان می‌دهد آمار ترافیک سرور را پرس‌وجو کنید و کلاینت‌ها را از طریق API HTTP قطع کنید. برای نقاط پایانی و نحوه استفاده، لطفاً به مستندات API آمار ترافیک مراجعه کنید.

trafficStats:
  listen: :9999 # (1)!
  secret: some_secret # (2)!

1. آدرس گوش‌دادن.
2. کلید محرمانه برای احراز هویت. آن را به هدر Authorization در درخواست‌های HTTP خود اضافه کنید.

توجه: اگر کلید محرمانه تنظیم نکنید، هر کسی که به آدرس گوش‌دادن API شما دسترسی داشته باشد می‌تواند آمار ترافیک را مشاهده کند و کاربران را قطع کند. ما اکیداً توصیه می‌کنیم کلید محرمانه تنظیم کنید، یا حداقل از ACL برای مسدود کردن دسترسی کاربران به API استفاده کنید.

استتار

یکی از کلیدهای مقاومت Hysteria در برابر سانسور، توانایی آن در استتار به عنوان ترافیک استاندارد HTTP/3 است. این بدان معناست که نه تنها بسته‌ها برای تجهیزات میانی به عنوان HTTP/3 به نظر می‌رسند، بلکه سرور نیز مانند یک وب‌سرور معمولی به درخواست‌های HTTP پاسخ می‌دهد. با این حال، این بدان معناست که سرور شما باید واقعاً محتوایی ارائه دهد تا برای ناظران احتمالی معتبر به نظر برسد.

اگر سانسور نگرانی شما نیست، می‌توانید بخش masquerade را کاملاً حذف کنید. در این حالت Hysteria همیشه برای تمام درخواست‌های HTTP پاسخ «404 Not Found» برمی‌گرداند.

در حال حاضر Hysteria حالت‌های استتار زیر را ارائه می‌دهد:

• file: به عنوان سرور فایل ایستا عمل می‌کند و فایل‌ها را از یک دایرکتوری ارائه می‌دهد.
• proxy: به عنوان ریورس پراکسی عمل می‌کند و محتوا را از وب‌سایت دیگری ارائه می‌دهد.
• string: به عنوان سروری عمل می‌کند که همیشه یک رشته تعیین‌شده توسط کاربر را برمی‌گرداند.

masquerade:
  type: file | proxy | string # (7)!
  file:
    dir: /www/masq # (1)!
  proxy:
    url: https://some.site.net # (2)!
    rewriteHost: true # (3)!
    insecure: false # (4)!
  string:
    content: hello stupid world # (5)!
    headers: # (6)!
      content-type: text/plain
      custom-stuff: ice cream so good
    statusCode: 200 # (7)!

1. دایرکتوری برای ارائه فایل‌ها.
2. آدرس URL وب‌سایت پراکسی‌شده.
3. بازنویسی هدر Host برای مطابقت با وب‌سایت پراکسی‌شده. اگر وب‌سرور هدف از Host برای تعیین سایت مورد ارائه استفاده می‌کند، این گزینه لازم است.
4. غیرفعال‌سازی تأیید TLS برای وب‌سایت پراکسی‌شده.
5. رشته‌ای که برگردانده می‌شود.
6. اختیاری. هدرهایی که برگردانده می‌شوند.
7. اختیاری. کد وضعیتی که برگردانده می‌شود. به طور پیش‌فرض ۲۰۰.
8. لطفاً دستورالعمل‌های مربوط به «انتخابگر نوع» در بالای این صفحه را بخوانید.

می‌توانید پیکربندی استتار خود را با راه‌اندازی Chrome با یک پرچم ویژه (برای اجبار QUIC) تست کنید:

chrome --origin-to-force-quic-on=your.site.com:443 # (1)!

1. با نام دامنه سرور خود جایگزین کنید.

توجه: قبل از راه‌اندازی Chrome با این پرچم، مطمئن شوید که Chrome را کاملاً بسته‌اید تا هیچ فرآیند Chrome در پس‌زمینه اجرا نشود. در غیر این صورت پرچم اعمال نخواهد شد.

سپس به https://your.site.com بروید تا مطمئن شوید همه چیز طبق انتظار کار می‌کند.

استتار HTTP/HTTPS

وب‌سایت‌هایی که از HTTP/3 پشتیبانی می‌کنند معمولاً آن را به عنوان گزینه ارتقا ارائه می‌دهند و همچنین HTTP/HTTPS مبتنی بر TCP را در پورت‌های 80/443 فراهم می‌کنند. اگر می‌خواهید این رفتار را شبیه‌سازی کنید، می‌توانید از گزینه‌های listenHTTP و listenHTTPS برای فعال‌سازی استتار HTTP/HTTPS استفاده کنید. در این حالت نیازی به راه‌اندازی Chrome با پرچم ویژه ذکرشده در بالا نیست؛ می‌توانید با دسترسی به سایت مانند هر وب‌سایت دیگری آن را تست کنید.

masquerade:
  # ... (سایر گزینه‌های شما)
  listenHTTP: :80 # (1)!
  listenHTTPS: :443 # (2)!
  forceHTTPS: true # (3)!

1. آدرس گوش‌دادن HTTP (TCP).
2. آدرس گوش‌دادن HTTPS (TCP).
3. اجبار به استفاده از HTTPS. اگر فعال باشد، تمام درخواست‌های HTTP به HTTPS هدایت می‌شوند.

توجه: هیچ مدرکی وجود ندارد که فایروال‌های دولتی یا تجاری از «نبودن TCP HTTP/HTTPS» به عنوان روشی برای شناسایی سرورهای Hysteria استفاده کنند. این قابلیت فقط برای کاربرانی ارائه شده است که می‌خواهند «احتیاط بیشتری» به خرج دهند. و در این صورت، دلیلی برای گوش‌دادن روی پورت‌هایی غیر از پورت‌های پیش‌فرض 80/443 وجود ندارد (اگرچه Hysteria این امکان را فراهم می‌کند).