پرش به مطلب اصلی

خروجی وب

با خروجی وب می‌توانید اپلیکیشن خود را به‌صورت یک نسخه قابل اجرا در مرورگر منتشر کنید. این خروجی برای نمایش اپ روی دامنه یا زیرمسیر سایت مناسب است و معمولاً به‌صورت یک فایل ZIP در اختیار شما قرار می‌گیرد.


خروجی وب چه زمانی استفاده می‌شود؟

  • وقتی می‌خواهید اپ بدون نصب، داخل مرورگر اجرا شود
  • وقتی می‌خواهید نسخه وب اپ را روی سایت خود منتشر کنید
  • وقتی می‌خواهید یک نسخه دمو یا قابل اشتراک از اپ داشته باشید
  • وقتی قصد دارید اپ را روی یک ساب‌دامین یا پوشه از سایت قرار دهید

قبل از گرفتن خروجی وب به چه چیزهایی نیاز دارید؟

تنظیمات خروجی وب
تنظیمات خروجی وب اپ‌ادیتور

برای خروجی وب معمولاً باید این دو مقدار را مشخص کنید:

مسیر روت

مسیر روت مشخص می‌کند اپ وب شما قرار است در چه آدرسی از سایت اجرا شود.

مثال:

  • اگر اپ روی دامنه اصلی اجرا می‌شود: /
  • اگر اپ داخل یک پوشه اجرا می‌شود: /app/
  • اگر اپ روی یک بخش خاص از سایت است: /my-application/

این مقدار مهم است چون فایل‌های خروجی وب باید بدانند از چه مسیری بارگذاری شوند.

لینک پراکسی

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

پراکسی کمک می‌کند:

  • تصاویر از مسیر واسط بارگذاری شوند
  • محدودیت‌های مرورگر و درخواست مستقیم تا حدی مدیریت شوند
  • نمایش منابع خارجی در نسخه وب پایدارتر شود

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


فرایند کلی گرفتن خروجی وب

  1. تنظیمات اپ را نهایی کنید
  2. مسیر روت را مطابق محل استقرار روی سرور مشخص کنید
  3. لینک پراکسی را ثبت و تست کنید
  4. خروجی وب را بسازید
  5. فایل ZIP تولیدشده را دریافت کنید
  6. محتویات ZIP را روی هاست یا سرور آپلود کنید
  7. تنظیمات وب‌سرور (در صورت نیاز) را اعمال کنید
  8. آدرس نهایی را در مرورگر و روی موبایل تست کنید
چک‌لیست قبل از استقرار
  • مسیر روت با محل آپلود فایل‌ها یکسان است
  • لینک پراکسی فعال و قابل دسترس است
  • اگر از fetch یا API در اجرای کد جاوااسکریپت استفاده می‌کنید، در نسخه وب محدودیت CORS را در نظر گرفته‌اید
  • صفحه اصلی، تصاویر و مسیرهای داخلی اپ تست شده‌اند

مسیر روت را چطور انتخاب کنیم؟

انتخاب مسیر روت به محل انتشار اپ بستگی دارد:

  • اگر اپ قرار است روی دامنه اصلی باشد، معمولاً روت / است
  • اگر اپ قرار است داخل یک پوشه از سایت باشد، روت باید همان پوشه باشد
  • اگر چند اپ روی یک دامنه دارید، برای هرکدام یک روت جداگانه تعریف کنید

مثال:

  • https://example.com/ ← روت: /
  • https://example.com/app/ ← روت: /app/
  • https://example.com/products/mobile-app/ ← روت: /products/mobile-app/

نکته مهم:

  • روت باید با محل واقعی آپلود فایل‌ها یکسان باشد
  • اگر روت اشتباه باشد، ممکن است فایل‌های JS، تصاویر یا مسیرهای داخلی درست لود نشوند

لینک پراکسی باید:

  • در دسترس و فعال باشد
  • روی دامنه یا سروری قرار داشته باشد که بتواند درخواست‌ها را پاسخ دهد
  • برای بارگذاری تصاویر و منابعی که اپ لازم دارد قابل استفاده باشد
  • با ساختار انتشار وب شما سازگار باشد

نکات پیشنهادی:

  • از یک آدرس پایدار استفاده کنید
  • اگر روی هاست خودتان پراکسی دارید، آدرس نهایی آن را دقیق وارد کنید
  • بعد از انتشار، چند تصویر و محتوای خارجی را حتماً در نسخه وب تست کنید

استفاده از پراکسی شخصی

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

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

در این حالت کافی است یک فایل PHP یا سرویس مشابه روی هاست خود قرار دهید و آدرس آن را به‌عنوان لینک پراکسی در تنظیمات خروجی وب وارد کنید.


نمونه پراکسی PHP

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

<?php
header("Access-Control-Allow-Origin: *");

if (!isset($_GET['url']) || empty($_GET['url'])) {
http_response_code(400);
echo "Missing url parameter";
exit;
}

$targetUrl = $_GET['url'];

if (!filter_var($targetUrl, FILTER_VALIDATE_URL)) {
http_response_code(400);
echo "Invalid url parameter";
exit;
}

$ch = curl_init($targetUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 20);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

$response = curl_exec($ch);
$contentType = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);

if ($response === false) {
http_response_code(502);
echo "Proxy request failed";
curl_close($ch);
exit;
}

curl_close($ch);

if (!empty($contentType)) {
header("Content-Type: " . $contentType);
}

http_response_code($httpCode ?: 200);
echo $response;

این پراکسی چطور استفاده می‌شود؟

فرض کنید این فایل را با نام proxy.php روی هاست خود قرار داده‌اید:

https://example.com/proxy.php

در این صورت، برای بارگذاری یک تصویر یا فایل از طریق پراکسی، درخواست نهایی به این شکل خواهد بود:

https://example.com/proxy.php?url=https://domain.com/image.jpg

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


نکات مهم درباره پراکسی شخصی

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

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


بعد از خروجی چه چیزی دریافت می‌کنید؟

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

این ZIP معمولاً شامل فایل‌ها و پوشه‌هایی برای اجرای نسخه وب است؛ مثل:

  • فایل اصلی HTML
  • فایل‌های JavaScript
  • فایل‌های تنظیمات و Assetها
  • پوشه‌های مربوط به منابع اپ

لازم نیست فایل‌های داخل ZIP را تغییر بدهید، مگر در شرایط خاصی که دقیقاً بدانید چه کاری انجام می‌دهید.


با فایل ZIP چطور کار کنیم؟

حالت ۱: انتشار روی هاست یا سرور

  1. فایل ZIP را روی سیستم خود دانلود کنید
  2. فایل را از حالت فشرده خارج کنید
  3. تمام محتویات داخل ZIP را (نه خود پوشه فشرده) در مسیر موردنظر روی هاست آپلود کنید
  4. مطمئن شوید مسیر آپلود با روت ثبت‌شده در تنظیمات خروجی وب یکسان است
  5. در صورت نیاز، تنظیمات وب‌سرور را اعمال کنید (بخش بعد)
  6. آدرس سایت را در مرورگر باز کنید و خروجی را تست کنید

مثال:

  • اگر روت شما /app/ است، فایل‌ها باید طوری آپلود شوند که اپ از https://example.com/app/ در دسترس باشد
  • اگر روت / است، فایل index.html باید در روت دامنه قرار بگیرد

حالت ۲: تحویل به تیم فنی یا پشتیبان سایت

اگر خودتان دسترسی مستقیم به هاست ندارید:

  1. فایل ZIP را به تیم فنی بدهید
  2. روت نهایی و لینک پراکسی ثبت‌شده را به آن‌ها اعلام کنید
  3. از آن‌ها بخواهید بعد از آپلود، صفحه اصلی، تصاویر، مسیرهای داخلی و نسخه موبایل را بررسی کنند

تنظیمات وب‌سرور برای استقرار

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

Apache

اگر هاست از Apache استفاده می‌کند، در همان پوشه‌ای که فایل‌های خروجی قرار گرفته‌اند یک فایل .htaccess بسازید:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /app/
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule . /app/index.html [L]
</IfModule>
یادداشت

مقدار RewriteBase و مسیر در RewriteRule باید با روت ثبت‌شده هماهنگ باشد. اگر روت / است، از / به‌جای /app/ استفاده کنید.

Nginx

در پیکربندی Nginx، برای مسیر اپ:

location /app/ {
try_files $uri $uri/ /app/index.html;
}

اگر اپ روی دامنه اصلی است:

location / {
try_files $uri $uri/ /index.html;
}

HTTPS

برای انتشار نهایی، استفاده از HTTPS توصیه می‌شود. بسیاری از قابلیت‌های مرورگر (مثل دسترسی به میکروفون، موقعیت مکانی یا بعضی درخواست‌های API) روی HTTP محدود می‌شوند.


بعد از آپلود چه چیزهایی را تست کنیم؟

بعد از استقرار نسخه وب، این موارد را حتماً بررسی کنید:

  • صفحه اصلی بدون خطا باز شود
  • مسیرهای داخلی اپ درست کار کنند
  • تصاویر به‌درستی نمایش داده شوند
  • محتواهای خارجی یا داینامیک درست بارگذاری شوند
  • اگر اپ روی زیرمسیر نصب شده، لینک‌ها و فایل‌ها خطای 404 ندهند
  • اگر از fetch یا API استفاده کرده‌اید، درخواست‌ها در نسخه وب هم تست شوند
  • نسخه موبایل مرورگر و دسکتاپ هر دو بررسی شوند

خطاهای رایج

تصاویر نمایش داده نمی‌شوند

معمولاً یکی از این علت‌ها وجود دارد:

  • لینک پراکسی درست ثبت نشده
  • پراکسی شخصی روی هاست به‌درستی سرویس‌دهی نمی‌کند
  • منبع تصویر از وب قابل دسترس نیست
  • مرورگر درخواست را به دلیل محدودیت‌های CORS یا ساختار بارگذاری رد کرده است

فایل‌ها لود نمی‌شوند

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

اپ در صفحه اصلی باز می‌شود ولی مسیرهای داخلی مشکل دارند

این مشکل معمولاً به تنظیم نادرست روت، مسیرها یا تنظیمات وب‌سرور (بازنویسی به index.html) مربوط است.

درخواست API یا fetch در نسخه وب کار نمی‌کند

معمولاً به محدودیت CORS مربوط است. راه‌حل‌ها:

  • استفاده از APIای که درخواست مرورگر را می‌پذیرد
  • عبور درخواست از پراکسی یا سرور واسط خودتان
  • مطالعه بخش فراخوانی API با fetch در راهنمای جاوااسکریپت

نکات مهم

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

این خروجی برای چه کسانی مناسب است؟

خروجی وب برای این گروه‌ها بسیار کاربردی است:

  • کسانی که می‌خواهند اپ را داخل سایت خود نمایش دهند
  • کسانی که نسخه دمو یا نسخه تحت وب برای مشتری می‌خواهند
  • تیم‌هایی که می‌خواهند یک اپ واحد را هم در موبایل و هم در وب ارائه کنند

ادامه مسیر