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

توزیعفایل منابعوضعیت میرور رسمی در ایران (آبان ۱۴۰۵)
اوبونتو 24.04/etc/apt/sources.list.d/ubuntu.sources۱۳ میرور ثبت‌شده در Launchpad که ۱۲ مورد به‌روز است
اوبونتو 22.04/etc/apt/sources.listهمان میرورهای اوبونتو 24.04
دبیان 12 و 13فایل /etc/apt/sources.list یا /etc/apt/sources.list.d/debian.sourcesیک میرور در فهرست رسمی دبیان
آلمالینوکس 9/etc/yum.repos.d/almalinux*.repoهفت میرور ثبت‌شده که دو مورد فعال است
راکی لینوکس 9/etc/yum.repos.d/rocky*.repoمیرور رسمی با کد کشور ایران ثبت نشده

💡 میرور یعنی کپی همگام مخزن رسمی، داخل شبکه کشور

✅ قبل از هر تغییر از فایل منابع بکاپ بگیرید تا برگشت فقط یک دستور باشد.
✅ دستورهای بازگشت را همان لحظه کنار دستورهای تغییر ذخیره کنید.

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

📌 آنچه در این مقاله می‌خوانید

◀️ چرا apt و dnf در اختلال اینترنت از کار می‌افتند؟
◀️ میرورهای اوبونتو، دبیان، آلمالینوکس و راکی را از کجا پیدا کنیم؟
◀️ تغییر sources.list و فایل‌های repo قدم‌به‌قدم
◀️ تست سلامت میرور، رفع خطاها و بازگشت به مخزن رسمی

قفسه سرور در دیتاسنتر با کابل‌های شبکه متصل به سوئیچ، میرور داخلی لینوکس

چرا apt و dnf در اختلال اینترنت از کار می‌افتند؟

مدیر بسته‌ها در لینوکس هر بار فهرست پکیج‌ها را از نشانی‌هایی می‌خواند که در فایل منابع نوشته شده است. این نشانی‌ها به‌طور پیش‌فرض سرورهای خارج از ایران هستند؛ پس وقتی مسیر بین‌الملل بسته یا کند شود، apt و dnf آن‌قدر منتظر می‌مانند تا با خطای اتصال یا Timeout متوقف شوند.

نشانی‌های پیش‌فرض هر توزیع

اوبونتو به‌طور پیش‌فرض به archive.ubuntu.com و security.ubuntu.com وصل می‌شود و دبیان به deb.debian.org که یک شبکه توزیع محتوای جهانی است. در بعضی نصب‌ها، نصب‌کننده یا ارائه‌دهنده سرور از قبل یک میرور کشوری یا میرور خودش را نوشته است. آلمالینوکس و راکی هم ابتدا یک mirrorlist از سرور مرکزی پروژه می‌گیرند تا نزدیک‌ترین میرور را انتخاب کنند. در حالت عادی این سازوکار خوب کار می‌کند، اما خودِ گرفتن mirrorlist هم به اینترنت بین‌الملل نیاز دارد.

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

# Ubuntu 24.04 / Debian 13
grep -h '^URIs' /etc/apt/sources.list.d/*.sources
# Ubuntu 22.04 / Debian 12
grep -h '^deb ' /etc/apt/sources.list
# AlmaLinux / Rocky
grep -h -E '^(mirrorlist|baseurl|#baseurl|# baseurl)' /etc/yum.repos.d/*.repo

خطاهایی که در اختلال می‌بینید

  • در apt: پیام Failed to fetch یا Could not connect و در پایان Some index files failed to download.
  • در dnf: پیام Curl error (28): Timeout was reached هنگام دریافت repomd.xml یا mirrorlist.
  • گاهی کندی چنددقیقه‌ای با قفل شدن apt اشتباه گرفته می‌شود؛ اگر پیام قفل دیدید، روش‌های رفع خطای Could not get lock در اوبونتو را ببینید.

میرور داخلی لینوکس فقط مسیر دانلود را عوض می‌کند و به اعتبار بسته‌ها دست نمی‌زند. ابزار apt امضای فایل InRelease و هش هر بسته را بررسی می‌کند و dnf امضای خود هر بسته را. اگر میرور معتبر باشد و این بررسی‌ها روشن بمانند، امنیت به‌روزرسانی کم نمی‌شود.

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

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

توزیعفهرست رسمیمیرورهای ایران در زمان بررسی
اوبونتوLaunchpad Archive Mirrors۱۳ میرور ثبت‌شده که ۱۲ مورد Up to date است، به‌علاوه نشانی کشوری ir.archive.ubuntu.com
دبیانDebian Worldwide Mirror Sitesیک میرور با نشانی mirror.famaserver.com
آلمالینوکسAlmaLinux Mirrorsهفت میرور ثبت‌شده؛ دو مورد با وضعیت ok (Sindad و FamaServer)
راکی لینوکسRocky MirrorManagerمیرور فعالی با کد کشور ایران دیده نشد

نشانی کشوری اوبونتو

اوبونتو برای هر کشور یک نشانی کوتاه دارد که به یک میرور داخل همان کشور اشاره می‌کند و Canonical مقصد آن را تعیین می‌کند. برای ایران این نشانی ir.archive.ubuntu.com است و ساده‌ترین انتخاب برای شروع کار است، چون لازم نیست نام میرور خاصی را به خاطر بسپارید. در زمان بررسی، این نشانی از طریق HTTP پاسخ می‌داد ولی اتصال HTTPS آن را نتوانستیم تأیید کنیم؛ برای همین در دستورهای این مقاله از http استفاده شده که با بررسی امضا امن می‌ماند. اگر سرعتش راضی‌کننده نبود، از جدول Launchpad یکی از میرورهای دیگر با وضعیت Up to date را بردارید.

دبیان و خانواده RHEL

دبیان فقط یک میرور ایرانی رسمی دارد؛ پس برای سرورهای دبیان یک برنامه جایگزین مثل کش داخلی با apt-cacher-ng مهم‌تر است. از هفت میرور ایرانی آلمالینوکس پنج مورد وضعیت expired داشتند و راکی میرور رسمی ایرانی ندارد.

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

🔸 امضا امنیت را تأمین می‌کند، HTTPS محرمانگی را

ابزار apt امضای فایل InRelease و هش هر بسته را بررسی می‌کند و dnf امضای خود هر بسته را. پس میرور HTTP هم نمی‌تواند بسته دستکاری‌شده را جا بزند، به شرط اینکه این بررسی‌ها را خاموش نکنید. چیزی که HTTPS اضافه می‌کند محرمانگی دانلود است و اینکه یک واسطه نتواند فهرست قدیمی ولی امضاشده را به‌جای فهرست تازه تحویل دهد.

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

تغییر sources.list و فایل‌های repo قدم‌به‌قدم

تغییر میرور در عمل یعنی عوض کردن یک نشانی در فایل منابع. قبل از هر چیز از فایل فعلی بکاپ بگیرید و بکاپ را در /root نگه دارید. اگر بکاپ کنار فایل اصلی در sources.list.d بماند، apt درباره پسوند ناآشنای آن هشدار چاپ می‌کند.

دستورهای این بخش برای اوبونتو 22.04 و 24.04، دبیان 12 و 13 و آلمالینوکس و راکی 9 روی معماری x86_64 نوشته شده‌اند. روی آلمالینوکس و راکی 10 هم همین منطق کار می‌کند، چون مسیرها با متغیر $releasever ساخته می‌شوند.

اوبونتو 24.04 با فرمت deb822

در اوبونتو 24.04 منابع در فایل ubuntu.sources و با فرمت deb822 نوشته می‌شوند. دستور زیر همه سطرهای URIs، چه بخش اصلی و چه بخش امنیتی، را به نشانی کشوری می‌برد؛ مهم نیست قبلاً به archive.ubuntu.com اشاره می‌کردند یا به میرور ارائه‌دهنده:

grep -h '^URIs' /etc/apt/sources.list.d/ubuntu.sources
sudo mkdir -p /root/apt-backup
sudo cp -a /etc/apt/sources.list.d/ubuntu.sources /root/apt-backup/
sudo sed -i -E 's|^URIs: .*|URIs: http://ir.archive.ubuntu.com/ubuntu/|' /etc/apt/sources.list.d/ubuntu.sources
grep -h '^URIs' /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

بخش اصلی فایل بعد از تغییر باید شبیه این باشد و سطر Signed-By دست‌نخورده بماند:

Types: deb
URIs: http://ir.archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

اوبونتو 22.04

در اوبونتو 22.04 منابع در فایل /etc/apt/sources.list با قالب یک‌خطی نوشته می‌شوند. این دستور هم نشانی اصلی، با یا بدون پیشوند کشوری، و هم نشانی امنیتی را عوض می‌کند:

sudo mkdir -p /root/apt-backup
sudo cp -a /etc/apt/sources.list /root/apt-backup/
sudo sed -i -E -e 's|https?://([a-z]{2}\.)?archive\.ubuntu\.com/ubuntu/?|http://ir.archive.ubuntu.com/ubuntu/|g' \
               -e 's|https?://security\.ubuntu\.com/ubuntu/?|http://ir.archive.ubuntu.com/ubuntu/|g' /etc/apt/sources.list
sudo apt update

دبیان 12 و 13

در دبیان 12 منابع در فایل /etc/apt/sources.list است. دبیان 13 در نصب‌های تازه از فایل /etc/apt/sources.list.d/debian.sources استفاده می‌کند و دستور apt modernize-sources هم فایل قدیمی را به همین قالب می‌برد. میرور FamaServer مخزن debian-security را ندارد؛ پس فقط سطر اصلی را عوض کنید. الگوهای زیر طوری نوشته شده‌اند که سطر debian-security را نگیرند:

sudo mkdir -p /root/apt-backup

# Debian 12: /etc/apt/sources.list
sudo cp -a /etc/apt/sources.list /root/apt-backup/
sudo sed -i 's|http://deb.debian.org/debian/\? |http://mirror.famaserver.com/debian/ |' /etc/apt/sources.list

# Debian 13: /etc/apt/sources.list.d/debian.sources
sudo cp -a /etc/apt/sources.list.d/debian.sources /root/apt-backup/
sudo sed -i 's|^URIs: http://deb.debian.org/debian/\?$|URIs: http://mirror.famaserver.com/debian/|' /etc/apt/sources.list.d/debian.sources

sudo apt update

در زمان اختلال، سطر امنیتی همچنان به نشانی رسمی اشاره می‌کند و apt برای آن هشدار Failed to fetch می‌دهد. این هشدار مورد انتظار است و بقیه بسته‌ها از میرور نصب می‌شوند.

آلمالینوکس 9

در آلمالینوکس هر مخزن یک سطر mirrorlist فعال و یک سطر baseurl غیرفعال دارد. سطر mirrorlist را غیرفعال و baseurl را با نشانی میرور داخلی فعال کنید؛ مقدار gpgcheck=1 باید دست‌نخورده بماند:

sudo cp -a /etc/yum.repos.d /root/yum.repos.d.bak-$(date +%F)
sudo sed -i -e 's|^mirrorlist=|#mirrorlist=|' \
            -e 's|^# baseurl=https://repo.almalinux.org/almalinux|baseurl=http://ir.almalinux.sindad.cloud|' \
            /etc/yum.repos.d/almalinux*.repo
sudo dnf clean all && sudo dnf makecache

پیش از اجرا، نشانی http://ir.almalinux.sindad.cloud/9/BaseOS/x86_64/os/ را در مرورگر باز کنید تا مطمئن شوید ساختار پوشه‌ها درست است. سطر baseurl نهایی در فایل almalinux-baseos.repo باید این شکل را داشته باشد:

baseurl=http://ir.almalinux.sindad.cloud/$releasever/BaseOS/$basearch/os/

راکی لینوکس 9

چون راکی میرور رسمی ایرانی ندارد، دو راه عملی دارید: میرور یک دیتاسنتر داخلی که بسته‌های امضاشده راکی را منتشر می‌کند، یا کپی محلی که قبل از اختلال گرفته‌اید. الگوی فایل‌های راکی با آلمالینوکس فرق دارد؛ سطر baseurl در آن بدون فاصله بعد از # و با متغیر $contentdir نوشته شده است. پس دستور آلمالینوکس را روی راکی اجرا نکنید و از این نسخه استفاده کنید:

MIRROR=http://mirror.example.ir/rocky   # replace with your domestic Rocky mirror
sudo cp -a /etc/yum.repos.d /root/yum.repos.d.bak-$(date +%F)
sudo sed -i -e 's|^mirrorlist=|#mirrorlist=|' \
            -e "s|^#baseurl=http://dl.rockylinux.org/\$contentdir|baseurl=$MIRROR|" \
            /etc/yum.repos.d/rocky*.repo
sudo dnf clean all && sudo dnf makecache

برای کپی محلی، در روزهای عادی مخزن‌های اصلی را با reposync روی دیسک بگیرید. این کار فضای زیادی می‌خواهد؛ پیش از شروع، فضای آزاد دیسک را بررسی کنید:

sudo dnf install -y dnf-plugins-core
sudo dnf reposync --repoid=baseos --repoid=appstream --download-metadata -p /srv/rocky-mirror

بعد از آن، یک فایل repo بسازید که به همین پوشه اشاره کند و بررسی امضا در آن روشن باشد:

[local-baseos]
name=Local BaseOS
baseurl=file:///srv/rocky-mirror/baseos/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

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

⚠️ بررسی امضا را هرگز خاموش نکنید

گزینه‌هایی مثل [trusted=yes] در apt یا gpgcheck=0 در dnf خطا را پنهان می‌کنند و مشکل را از بین نمی‌برند. اگر میرور فقط با این گزینه‌ها کار می‌کند، آن میرور مشکل دارد و باید عوض شود.

تغییر sources.list و فایل‌های repo قدم‌به‌قدم

تست سلامت میرور، رفع خطاها و بازگشت به مخزن رسمی

میرور سالم دو نشانه دارد: فایل Release آن تازه است و apt update در چند ثانیه تمام می‌شود. این دو را قبل از تکیه کردن به میرور بسنجید و اگر خطایی دیدید، علت را از جدول همین بخش پیدا کنید.

سنجش تازگی و سرعت

تاریخ Last-Modified فایل InRelease میرور را با تاریخ امروز مقایسه کنید. وقتی مخزن اصلی در دسترس است، همین دستور را روی archive.ubuntu.com هم بزنید و دو تاریخ را کنار هم بگذارید. اختلاف چندساعته طبیعی است، اما اختلاف چندروزه یعنی میرور از همگام‌سازی جا مانده و نباید برای وصله‌های امنیتی به آن تکیه کرد:

curl -sI http://ir.archive.ubuntu.com/ubuntu/dists/noble-updates/InRelease | grep -i last-modified
date -u
time sudo apt update

در آلمالینوکس و راکی به‌جای آن از دستور زیر استفاده کنید و مقدار Repo-updated هر مخزن را ببینید:

dnf repolist -v | grep -i -E 'repo-id|repo-updated'

خطاهای رایج و راه حل

پیام خطاعلت محتملراه حل
NO_PUBKEYامضای Release با کلیدی غیر از کلید رسمی توزیع ساخته شده؛ میرور دستکاری‌شده یا مخزن شخص ثالثمیرور را از فهرست رسمی انتخاب کنید و کلید ناشناس اضافه نکنید
Release file is not valid yetساعت سرور عقب استبا timedatectl ساعت و NTP را درست کنید
Hash Sum mismatchمیرور وسط همگام‌سازی استفهرست‌ها را پاک کنید و دوباره امتحان کنید یا میرور را عوض کنید
does not have a Release fileمسیر یا نام Suite اشتباه استنشانی را در مرورگر باز کنید و پوشه dists را بررسی کنید
خطای 404 برای repomd.xmlساختار پوشه میرور با baseurl جور نیستمسیر $releasever/BaseOS/$basearch/os/ را روی میرور چک کنید
GPG check FAILEDامضای بسته با کلید نصب‌شده تطابق نداردگزینه gpgcheck را خاموش نکنید؛ میرور را عوض کنید

⚠️ دستورهای زیر فهرست بسته‌های فعلی را پاک می‌کنند. آن‌ها را فقط وقتی اجرا کنید که دستور curl بالا نشان داده میرور پاسخ می‌دهد؛ وگرنه سرور تا رفع اختلال بدون فهرست بسته می‌ماند:

sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
sudo apt update

بازگشت به مخزن رسمی

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

# Ubuntu 24.04
sudo cp -a /root/apt-backup/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources
# Ubuntu 22.04 and Debian 12
sudo cp -a /root/apt-backup/sources.list /etc/apt/sources.list
# Debian 13
sudo cp -a /root/apt-backup/debian.sources /etc/apt/sources.list.d/debian.sources
sudo apt update

# AlmaLinux: restore only the files you changed
sudo cp -a /root/yum.repos.d.bak-YYYY-MM-DD/almalinux*.repo /etc/yum.repos.d/
# Rocky Linux
sudo cp -a /root/yum.repos.d.bak-YYYY-MM-DD/rocky*.repo /etc/yum.repos.d/
sudo dnf clean all && sudo dnf makecache

این روش فقط فایل‌های تغییرکرده را برمی‌گرداند و مخزن‌هایی مثل EPEL یا Docker سر جایشان می‌مانند. اگر چند سرور دارید، فایل منابع را با یک ابزار مدیریت پیکربندی مثل Ansible یکسان نگه دارید تا جابه‌جایی بین مخزن رسمی و میرور داخلی لینوکس برای همه سرورها با یک اجرا انجام شود. برای بقیه تنظیمات پایه سرور هم ده گام امن‌سازی سرور مجازی لینوکس را ببینید.

🔶 نکته برای کاربران وب‌داده

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

سوالات متداول درباره مخزن داخلی لینوکس

آیا استفاده از میرور ایرانی امنیت به‌روزرسانی را کم می‌کند؟

نه، به شرط اینکه بررسی امضا روشن بماند. apt امضای فهرست مخزن و هش بسته‌ها را بررسی می‌کند و dnf امضای خود بسته‌ها را؛ میرور فقط آن‌ها را نگه می‌دارد. خطر وقتی است که برای رفع خطا گزینه [trusted=yes] یا gpgcheck=0 را فعال کنید.

این نشانی کشوری اوبونتو است و به یک میرور داخل ایران اشاره می‌کند که Canonical تعیین می‌کند. مقصد آن ممکن است تغییر کند و الزاماً یکی از نام‌های جدول Launchpad نیست؛ اگر سرعت مناسب نبود، یک میرور مشخص از همان فهرست انتخاب کنید.

میرورهای کامل آرشیو، بخش‌های noble-security و jammy-security را هم منتشر می‌کنند، اما ممکن است کمی از security.ubuntu.com عقب بمانند. تازگی را با Last-Modified بسنجید و بعد از پایان اختلال به مخزن رسمی برگردید.

در بررسی آبان ۱۴۰۵ در فهرست MirrorManager راکی، میرور فعالی با کد کشور ایران ثبت نشده بود. برای سرور راکی، کپی محلی با reposync یا میرور یک دیتاسنتر داخلی با gpgcheck=1 را قبل از اختلال آماده کنید.

اول زمان اجرا را با time بسنجید و یک میرور دیگر از فهرست رسمی را امتحان کنید. اگر کندی فقط در شروع اتصال است، احتمالاً apt روی IPv6 معطل می‌شود؛ گزینه Acquire::ForceIPv4 را تست کنید.

در اوبونتو و دبیان دستور apt-cache policy نشانی هر مخزن فعال را نشان می‌دهد. در آلمالینوکس و راکی دستور dnf repolist -v مقدار baseurl یا mirrorlist هر مخزن را چاپ می‌کند.

بله. با ابزاری مثل apt-cacher-ng برای دبیان و اوبونتو یک کش داخلی می‌سازید تا هر بسته فقط یک بار دانلود شود. این روش در اختلال طولانی، وابستگی همه سرورها به یک میرور بیرونی را هم کم می‌کند.

جمع‌بندی؛ آماده شدن قبل از قطعی بعدی وقتی اینترنت بین‌الملل قطع است، وقت پیدا کردن نشانی میرور و آزمودن دستور sed نیست. میرور داخلی لینوکس را در روزهای عادی پیدا و تست کنید. از فایل منابع در /root بکاپ بگیرید و دستورهای تغییر و بازگشت را کنار سرور نگه دارید. برای اوبونتو نشانی کشوری ir.archive.ubuntu.com با http شروع خوبی است؛ در دبیان فقط سطر اصلی را عوض کنید. برای آلمالینوکس میرورهای Sindad و FamaServer را بررسی کنید و برای راکی، کپی محلی با reposync مطمئن‌ترین گزینه است. بررسی امضا را همیشه روشن نگه دارید و بعد از پایان اختلال فایل‌های بکاپ را برگردانید.

🚀 سرور لینوکس در دیتاسنتر تهران

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

مشاهده پلن‌های سرور مجازی ایران

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

منابع

به اشتراک بگذارید
وب داده
وب داده

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

مقاله‌ها: 236

نوشته‌ای مرتبط

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *