برای سال‌ها، زیرساخت‌های عمومی و خصوصی مثل دو دنیای جدا عمل می‌کردند: برنامه‌های عمومی پشت CDNها و WAF قرار داشتند و برنامه‌های خصوصی پشت VPN، فایروال‌ها و استک‌های عملیاتی جدا. این تفکیک به‌تدریج منسوخ شده است 🚧

بسیاری از اپلیکیشن‌هایی که برای سازمان‌ها اهمیت دارند، سایت‌های عمومی نیستند. آن‌ها internal APIs، AI agent backends، MCP servers، ابزارهای عملیاتی و سرویس‌هایی هستند که هرگز برای در معرض اینترنت عمومی قرار گرفتن طراحی نشده‌اند. با این حال این برنامه‌ها به خدمات امنیتی، عملکردی و programmability مدرن نیاز دارند. امنیت باید یک خصوصیتِ ترافیکی باشد که به اپلیکیشن می‌رسد، نه تصادفی وابسته به محلی که اپلیکیشن در آن قرار دارد 🔒

تا امروز، اعمال این خدمات روی برنامه‌های خصوصی معمولاً نیازمند IP عمومی، استثناهای فایروال، نرم‌افزار connector یا شبکه‌بندی پیچیده بود. در نتیجه بسیاری از برنامه‌های خصوصی از امکاناتی مثل WAF، bot management، rate limiting، caching، traffic acceleration، rewrites و Workers محروم می‌ماندند، در حالی که دقیقاً به همان محافظت‌ها نیاز داشتند.

امروز قابلیت Application Services for Private Origins را در closed beta برای مشتریان Enterprise واجد شرایط عرضه می‌کنیم. حالا امکان مسیردهی امن ترافیک به private origins بدون در معرض اینترنت عمومی قرار دادن آن‌ها وجود دارد. این یعنی خدمات امنیتی، عملکردی و programmabilityِ Cloudflare می‌توانند اپلیکیشن‌های درون شبکه خصوصی را همانند اپلیکیشن‌های اینترنتی محافظت کنند ⚡️

قوانین WAF، bot management، rate limiting، caching، rewrites و Workers حالا می‌توانند جلوی private origins قرار بگیرند بدون نیاز به public IP، قوانین inbound فایروال یا اجرای cloudflared روی origin.

این مدل مسیردهی بر پایه الگوهای کانکتویتی‌ای ساخته شده که Cloudflare هم‌اکنون از آن‌ها پشتیبانی می‌کند: Cloudflare Tunnel، Cloudflare One Client و private network integrations. برای سال‌ها Cloudflare Tunnel اجازه داده بود traffic عمومی از طریق cloudflared به برنامه‌های خصوصی برود؛ این قابلیت جدید همان الگو را به Cloudflare WAN و Cloudflare Mesh تعمیم می‌دهد، بدون نیاز به نرم‌افزار connector روی origin.

بخش زیادی از آن کانکتویتی از طریق لایه routing شبکه خصوصی Cloudflare ارکستره می‌شود؛ لایه‌ای که مشخص می‌کند ترافیک چگونه از طریق Cloudflare Tunnels، Virtual Networks، Cloudflare Mesh و مدل‌های دیگر به مقصدهای خصوصی برسد. مشتریان می‌توانند رفتار روتینگ را از طریق APIها و داشبورد تعریف کنند به جای مدیریت استک شبکه مجزا برای هر محصول. ما این لایه را مستقیم به application services stack متصل کردیم تا proxyهای امنیتی و عملکردی بتوانند private IPها را به‌عنوان originهای معتبر برای public hostnames در نظر بگیرند. در نتیجه همان IPهای خصوصی که قبلاً فقط از طریق Cloudflare Tunnel، Cloudflare One، Cloudflare Mesh یا Cloudflare WAN در دسترس بودند، حالا می‌توانند پشت خدمات Cloudflare قرار بگیرند همانند originهای عمومی.

این تغییر باعث ایجاد یک مدل یکپارچه‌تر در بین محصولات Cloudflare می‌شود. Workers VPC bindings و Spectrum private origin routing اکنون روی همان لایه کانکتویتی خصوصی پایه تکیه دارند و به مشتریان یک منبع واحد برای کنترل نحوه حرکت ترافیک خصوصی در محیط Cloudflare می‌دهند.

ترافیک اپلیکیشن حالا به چهار ترکیب تقسیم می‌شود بر اساس اینکه کاربران از کجا می‌آیند و اپلیکیشن‌ها کجا قرار دارند: ترکیب بالا-راست همان چیزی است که Cloudflare همیشه انجام داده: کاربران اینترنت به اپلیکیشن‌های اینترنتی می‌رسند و Cloudflare وسط است. پایین-راست همان Cloudflare One است: کاربران در شبکه‌های خصوصی به سرویس‌های عمومی به‌صورت امن دسترسی دارند. بالا-چپ همان چیزی است که امروز عرضه می‌کنیم: کاربران اینترنت به private origins دسترسی دارند. پایین-چپ (private-to-private) هدف بعدی ماست که در آینده به آن خواهیم رسید.

تا امروز، فرستادن ترافیک عمومی به یک private origin معمولاً با مصالحه‌هایی همراه بود. مشتریان می‌توانستند از Cloudflare Tunnel استفاده کنند (cloudflared روی یا نزدیک origin اجرا شود) یا از Cloudflare Load Balancing با private origin pools برای health checks و failover بهره ببرند. اغلب سازمان‌ها همچنین زیرساخت‌های موازی مثل load balancerهای public-facing، reverse proxy، mTLS بین هاپ‌ها و termination چندلایه TLS را نگه می‌داشتند. در نتیجه اعمال کامل Application Services روی برنامه‌های خصوصی معمولاً پیچیدگی و سربار عملیاتی بیشتری می‌طلبید. Application Services for Private Origins این معامله‌ها را حذف می‌کند.

آنچه کم بود مسیری برای مشتریانی بود که قبلاً Cloudflare WAN (IPsec tunnels, GRE tunnels, CNI links) یا Cloudflare Mesh را اجرا کرده بودند. آن‌ها کانکتویتی خصوصی را برای site-to-site networking و Zero Trust ساختند و می‌خواستند از همان کانکتویتی برای ترافیک عمومی به private origins استفاده کنند — و این دقیقاً چیزی است که Application Services for Private Origins فراهم می‌کند.

وقتی گزینه Use private network routing را روی یک رکورد A یا AAAA که proxied شده روشن می‌کنید، WAF، rate limiting، caching، bot management و transform rules همان‌طور که در شبکه Cloudflare اجرا می‌شوند، اجرا خواهند شد. تنها تفاوت در هاپ آخر است: به جای رسیدن به origin از طریق اینترنت عمومی، Cloudflare اتصال را از طریق کانکتویتی شبکه خصوصی موجود شما روت می‌کند 🔁

این گزینه به‌صورت خودکار برای بازه‌های IPv4 خصوصی RFC 1918 (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x)، بازه‌های CGNAT RFC 6598 (100.64.x.x–100.127.x.x) و آدرس‌های Unique Local IPv6 RFC 4193 (FC00::/7) فعال می‌شود، چون این آدرس‌ها فقط در شبکه‌های خصوصی قابل دسترسی‌اند. برای آدرس‌های public که تنها از طریق شبکه یا تونل خصوصی شما قابل دسترسی‌اند، می‌توانید این گزینه را به‌صورت دستی فعال کنید.

برای مشتریانی که استقرارها را با API خودکار می‌کنند، private routing صرفاً یک صفت اضافی روی یک رکورد DNS استاندارد است. نمونه درخواست API:

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "use_private_routing": true
}

در پس‌زمینه، proxy پلتفرم Cloudflare تعیین می‌کند ترافیک برای app.example.com را کجا ارسال کند با پرس‌وجو از Cloudflare’s Origin API. پاسخ متادیتایی شامل این است که مقصد باید از طریق یک مسیر شبکه خصوصی برسد:

{
  "zone_name": "example.com",
  "ipv4_addresses": ["10.0.0.50"],
  "use_private_routing": true
}

فلگ use_private_routing سیگنال کلیدی است. وقتی proxy این را ببیند، به‌جای تلاش برای اتصال مستقیم به آدرس private IP روی اینترنت عمومی، درخواست را به لایه شبکه خصوصی ما می‌سپارد که سپس اتصال را از طریق کانکتویتی خصوصی موجود مشتری (IPsec, GRE, Cloudflare Tunnel, CNI, یا Cloudflare Mesh) روت می‌کند.

فراتر از HTTP: Spectrum و Workers VPC — همین مدل مسیردهی اکنون فراتر از برنامه‌های HTTP گسترش یافته است. origin لازم نیست لزوماً یک وب‌سرور باشد؛ می‌تواند یک دیتابیس TCP، یک endpoint لاگ‌گیری UDP یا یک private API باشد که Workers مستقیماً آن را صدا می‌زنند. نکته مشترک این است که Cloudflare بین ترافیک شما و شبکه خصوصی شما می‌ایستد و همان لایه امنیت، عملکرد و روتینگ را صرف‌نظر از پروتکل یا مبدأ درخواست اعمال می‌کند.

Spectrum، پروکسی Layer 4 Cloudflare، حالا می‌تواند جلوی سرویس‌های TCP و UDP روی آدرس‌های private بنشیند. به‌جای ساختن یک load balancer pool واسط، اپلیکیشن‌های Spectrum می‌توانند virtual_network_id را مستقیماً در پیکربندی origin مشخص کنند. نمونه پیکربندی Spectrum:

{
  "protocol": "tcp/22",
  "dns": {
    "type": "CNAME",
    "name": "ssh.example.com"
  },
  "origin_direct": ["tcp://10.0.0.50:22"],
  "virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}

وقتی یک اپلیکیشن Spectrum با origin خصوصی و virtual network ایجاد یا بروزرسانی می‌کنید، Cloudflare بررسی می‌کند که آیا آدرس IP با یک route در Cloudflare Tunnel شما مطابقت دارد یا نه؛ اگر Route ای پیدا نشود، API درخواست را رد می‌کند و اپلیکیشن ایجاد نخواهد شد. پس از ذخیره شدن، Spectrum اتصال را به virtual network شما می‌سپارد که از طریق تونل مرتبط آن را روت می‌کند، همان مسیری که ترافیک HTTP هنگام فعال‌سازی private network routing روی رکورد DNS استفاده می‌کند. در این نسخه اولیه، private origins برای Spectrum از طریق Cloudflare Tunnel پشتیبانی می‌شوند؛ پشتیبانی از گزینه‌های کانکتویتی خصوصی بیشتر در نسخه‌های بعدی اضافه خواهد شد.

این یعنی حالا می‌توانید Spectrum را جلوی هر سرویس TCP/UDP که روی یک private IP اجرا می‌شود قرار دهید. سرویس خصوصی می‌ماند؛ نیازی به IP عمومی، نرم‌افزار connector یا load balancer نیست ✅

Workers VPC حلقه را برای کدهایی که روی Cloudflare اجرا می‌شوند می‌بندد. یک binding به runtime Workers می‌گوید که مسیر را از همان مسیر خصوصی‌ای که رکوردهای DNS استفاده می‌کنند طی کند. مرورگرها، اپ موبایل، Workers و AI agents همه از طریق Cloudflare به private origins شما دسترسی پیدا می‌کنند: رکوردهای DNS برای ترافیک اینترنتی، bindings برای Workers.

چه چیز بعدی است — مسیر public-to-private هم‌اکنون در closed beta است و هدف‌گذاری ما برای GA (General Availability) در Q4 2026 است. پس از GA، روی جریان‌های private-to-private کار می‌کنیم: کاربران، سرویس‌ها و AI agents در شبکه‌های خصوصی که به‌صورت امن به اپلیکیشن‌ها در شبکه‌های خصوصی دیگر دسترسی دارند، در حالی که application services Cloudflare میان این مسیرها قرار گرفته است.

ما به سمتی می‌رویم که زیرساخت یکسان Cloudflare بتواند ترافیک را فارغ از اینکه کاربر یا origin عمومی باشد، امن کند. حالت نهایی این است که یک کاربر داخل شبکه با Cloudflare One Client که به wiki.company.internal دسترسی دارد، همان محافظت‌های WAF، rate limiting و bot management را ببیند که یک مشتری عمومی از یک API مشاهده می‌کند؛ یک AI agent که از یک API داخلی استفاده می‌کند، از همان استک امنیتی عبور کند که یک مرورگر از آن می‌گذرد؛ و ترافیک سرویس-به-سرویس بین کلاودها و دیتاسنترها همان کنترل‌ها را داشته باشد که ترافیک اینترنتی دارد 🤝