رفع مشکل Docker بعد از تغییر IP سرور؛ بررسی شبکه، Port و Firewall

اگر IP سرور لینوکسی شما تغییر کرده و بعد از آن Docker یا سرویس‌های داخل Container از دسترس خارج شده‌اند، لزوماً نیازی به نصب مجدد Docker ندارید. در بیشتر مواقع مشکل از باقی‌ماندن IP قبلی در Port Mapping، فایل compose.yaml، متغیرهای محیطی، Reverse Proxy، DNS یا قوانین شبکه و فایروال است.

چرا تغییر IP سرور می‌تواند Docker را دچار مشکل کند؟

Containerهای Docker معمولاً IP داخلی خودشان را از شبکه‌های Docker دریافت می‌کنند؛ بنابراین تغییر Public IP سرور الزاماً IP داخلی Containerها را تغییر نمی‌دهد. مشکل زمانی ایجاد می‌شود که بخشی از تنظیمات Docker یا برنامه شما مستقیماً به IP قدیمی میزبان وابسته باشد.

موارد رایج عبارت‌اند از:

مرحله ۱: قبل از تغییر Docker، شبکه خود سرور را بررسی کنید

اول مطمئن شوید IP جدید واقعاً روی سرور قرار گرفته و Default Route نیز صحیح است. این مرحله روی خود سرور و از طریق SSH اجرا می‌شود.

ip addr
ip route

در خروجی ip addr باید IP جدید را روی Interface اصلی شبکه ببینید. نام Interface ممکن است eth0، ens3، enp1s0 یا نام دیگری باشد.

سپس دسترسی اینترنت میزبان را آزمایش کنید:

ping -c 4 1.1.1.1
ping -c 4 google.com

اگر حتی خود سرور به اینترنت دسترسی ندارد، فعلاً Docker را تغییر ندهید. ابتدا IP، Gateway، Route و DNS سیستم‌عامل را اصلاح کنید.

مرحله ۲: وضعیت Docker را بررسی کنید

sudo systemctl status docker --no-pager
docker ps -a

اگر Docker فعال است اما Containerها متوقف شده‌اند، علت توقف را جداگانه بررسی کنید. برای مثال:

docker logs --tail 100 CONTAINER_NAME

به‌جای CONTAINER_NAME نام Container موردنظر را از خروجی docker ps -a قرار دهید.

مرحله ۳: مهم‌ترین مورد؛ Port Mapping را بررسی کنید

یکی از مهم‌ترین علت‌های قطع سرویس بعد از تغییر IP همین قسمت است. دستور زیر را اجرا کنید:

docker ps

ستون PORTS را بررسی کنید. اگر قبلاً Container را به IP مشخصی متصل کرده باشید، ممکن است چیزی شبیه نمونه زیر ببینید:

192.0.2.10:8080->80/tcp

اگر 192.0.2.10 در این مثال IP قدیمی سرور باشد، تنظیم Port باید اصلاح شود.

تفاوت دو روش انتشار Port

این تنظیم:

ports:
  - "8080:80"

به‌طور معمول Port را روی Interfaceهای میزبان منتشر می‌کند؛ اما این حالت:

ports:
  - "192.0.2.10:8080:80"

صراحتاً Docker را به IP مشخصی از میزبان وابسته می‌کند. در نتیجه اگر IP میزبان تغییر کند، این تنظیم نیز باید بررسی و اصلاح شود.

مرحله ۴: IP قدیمی را در فایل‌های Docker Compose پیدا کنید

اگر پروژه با Docker Compose اجرا شده است، وارد پوشه پروژه شوید و فایل‌های Compose و Environment را بررسی کنید.

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

grep -R "192.0.2.10" . --exclude-dir=.git

مواردی مانند این‌ها را بررسی کنید:

مرحله ۵: قبل از اعمال Compose، کانفیگ نهایی را ببینید

بعد از اصلاح فایل‌ها، بهتر است ابتدا خروجی نهایی Compose را بررسی کنید:

docker compose config

این دستور کمک می‌کند مقادیری که از فایل .env یا متغیرهای دیگر وارد Compose شده‌اند نیز مشخص شوند.

اگر تنظیمات درست است، سرویس‌ها را مجدداً ایجاد کنید:

docker compose up -d

اگر تغییر مربوط به تنظیماتی است که نیازمند ایجاد مجدد Container هستند و Compose آن را بازسازی نکرد، می‌توانید پس از اطمینان از صحت تنظیمات از این فرمان استفاده کنید:

docker compose up -d --force-recreate

مرحله ۶: از IP ثابت Container برای ارتباط داخلی استفاده نکنید

در یک پروژه Compose، بهتر است Containerها با نام سرویس یکدیگر را پیدا کنند. Docker ممکن است هنگام ایجاد مجدد Container، IP داخلی جدیدی به آن بدهد؛ در حالی که نام سرویس ثابت باقی می‌ماند.

برای مثال اگر سرویس PostgreSQL شما db نام دارد، به‌جای چنین تنظیمی:

DB_HOST=172.18.0.5

در شبکه Compose معمولاً باید از نام سرویس استفاده شود:

DB_HOST=db

این روش وابستگی برنامه به IP داخلی متغیر Container را کاهش می‌دهد.

مرحله ۷: شبکه‌های Docker را بررسی کنید

docker network ls

برای مشاهده جزئیات یک Network:

docker network inspect NETWORK_NAME

به‌جای NETWORK_NAME نام شبکه واقعی را قرار دهید. Subnet، Gateway و Containerهای متصل را بررسی کنید.

تداخل Subnet شبکه جدید سرور با Docker

اگر همراه تغییر IP، ساختار شبکه یا Private Network سرور نیز تغییر کرده است، احتمال تداخل Subnet را بررسی کنید. برای مثال اگر شبکه زیرساخت جدید از محدوده‌ای استفاده کند که با یکی از Bridge Networkهای Docker هم‌پوشانی دارد، Routing می‌تواند غیرمنتظره شود.

برای مقایسه، خروجی این دو دستور را بررسی کنید:

ip route
docker network ls

سپس Network مشکوک را با docker network inspect بررسی کنید. Network را بدون بررسی Containerهای وابسته حذف نکنید.

مرحله ۸: IP Forwarding را بررسی کنید

Bridge Networking و Port Publishing در Docker لینوکس به Forwarding شبکه وابسته‌اند. وضعیت IPv4 Forwarding را ببینید:

sysctl net.ipv4.ip_forward

برای سناریوهای معمول Bridge که به Forwarding نیاز دارند، مقدار مورد انتظار 1 است:

net.ipv4.ip_forward = 1

اگر مقدار صفر است، قبل از تغییر دائمی آن بررسی کنید چرا غیرفعال شده و سرور چه نقش‌های شبکه‌ای دیگری دارد. فعال‌کردن Forwarding روی سرور چندشبکه‌ای باید همراه با سیاست Firewall مناسب انجام شود.

مرحله ۹: Firewall و NAT را بررسی کنید

Docker روی Linux برای Bridge Networkها قوانین Firewall و NAT ایجاد می‌کند. بنابراین بعد از تغییر IP، فقط بازبودن Port در UFW برای نتیجه‌گیری کافی نیست.

ابتدا وضعیت UFW را مشاهده کنید:

sudo ufw status verbose

اگر سیستم از iptables استفاده می‌کند، برای تشخیص وضعیت می‌توانید Ruleها را مشاهده کنید:

sudo iptables -L FORWARD -n -v
sudo iptables -t nat -L -n -v

در سیستم‌هایی که از nftables استفاده می‌کنند:

sudo nft list ruleset

مرحله ۱۰: بررسی کنید سرویس روی چه IP و Portی Listen می‌کند

sudo ss -lntup

اگر سرویس یا Proxy هنوز روی IP قدیمی Bind شده باشد، در این مرحله می‌توانید سرنخ مهمی پیدا کنید.

همچنین Port Mapping خود Container را دقیق‌تر ببینید:

docker port CONTAINER_NAME
docker inspect CONTAINER_NAME

مرحله ۱۱: اتصال از داخل Container را آزمایش کنید

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

یک تست ساده مستقل از Containerهای اصلی:

docker run --rm alpine ping -c 4 1.1.1.1

سپس DNS را نیز آزمایش کنید:

docker run --rm alpine nslookup example.com

اگر اتصال به 1.1.1.1 برقرار است ولی نام دامنه Resolve نمی‌شود، مشکل بیشتر به DNS مربوط است تا IP Public یا Port Mapping.

مرحله ۱۲: daemon.json را برای IP ثابت قدیمی بررسی کنید

فایل اصلی تنظیمات Docker Engine در بسیاری از سرورهای لینوکسی مسیر زیر است:

sudo cat /etc/docker/daemon.json

وجود تنظیمات سفارشی مربوط به Binding، DNS، Bridge یا شبکه را بررسی کنید. فایل را صرفاً به‌دلیل تغییر IP حذف نکنید؛ ممکن است تنظیمات ضروری دیگری داخل آن وجود داشته باشد.

اگر فایل را تغییر دادید، قبل از Restart کردن Docker از معتبر بودن JSON مطمئن شوید. در صورت نصب بودن Python می‌توانید از این روش استفاده کنید:

python3 -m json.tool /etc/docker/daemon.json

بعد از تأیید تنظیمات:

sudo systemctl restart docker
sudo systemctl status docker --no-pager

مرحله ۱۳: DNS دامنه را فراموش نکنید

گاهی Docker کاملاً سالم است و تنها رکورد DNS دامنه هنوز IP قدیمی را برمی‌گرداند. این موضوع مخصوصاً زمانی مهم است که Nginx، Traefik یا Caddy جلوی Containerها قرار گرفته باشد.

رکورد فعلی را بررسی کنید:

dig +short example.com

به‌جای example.com دامنه خودتان را وارد کنید. اگر خروجی هنوز IP قبلی است، رکورد A را در سرویس DNS فعال دامنه اصلاح کنید.

مرحله ۱۴: Reverse Proxy را بررسی کنید

اگر Nginx یا Reverse Proxy دیگری خارج از Docker اجرا می‌شود، فایل‌های کانفیگ آن را نیز برای IP قدیمی جست‌وجو کنید. برای Nginx می‌توانید ابتدا جست‌وجوی متنی انجام دهید:

sudo grep -R "192.0.2.10" /etc/nginx/

IP مثال را با IP قبلی خودتان جایگزین کنید.

بعد از اصلاح Nginx ابتدا Syntax را بررسی کنید:

sudo nginx -t

فقط در صورت موفق‌بودن بررسی کانفیگ:

sudo systemctl reload nginx

چطور بفهمیم مشکل دقیقاً کجاست؟

یک مسیر عیب‌یابی سریع و کم‌خطر

اگر نمی‌دانید از کجا شروع کنید، این ترتیب معمولاً سریع‌تر از حذف Networkها یا نصب مجدد Docker است:

مرحله ۱: با ip addr و ip route شبکه میزبان را بررسی کنید.

مرحله ۲: دسترسی اینترنت و DNS خود سرور را آزمایش کنید.

مرحله ۳: وضعیت Docker و Containerها را با docker ps -a ببینید.

مرحله ۴: ستون PORTS را برای IP قبلی بررسی کنید.

مرحله ۵: IP قبلی را در Compose، .env و Reverse Proxy جست‌وجو کنید.

مرحله ۶: DNS دامنه را بررسی کنید.

مرحله ۷: اینترنت و DNS را از داخل یک Container آزمایش کنید.

مرحله ۸: فقط اگر مشکل همچنان وجود دارد، Firewall، NAT، Forwarding و Docker Network را بررسی کنید.

آیا باید Docker را پاک و دوباره نصب کنیم؟

در اغلب موارد خیر. تغییر Public IP سرور به‌تنهایی دلیل مناسبی برای حذف Docker نیست. نصب مجدد حتی ممکن است عیب اصلی را پنهان کند، در حالی که IP قدیمی همچنان در Compose، DNS یا کانفیگ برنامه باقی مانده است.

همچنین برای رفع این مشکل از دستورهایی که همه Containerها، Networkها یا Volumeها را حذف می‌کنند استفاده نکنید؛ به‌خصوص اگر PostgreSQL، MySQL، MariaDB، Redis یا داده‌های برنامه روی Docker نگهداری می‌شوند.

پرسش‌های متداول

آیا با تغییر IP سرور باید IP داخلی Containerها را تغییر دهیم؟

معمولاً خیر. Public IP میزبان و IP داخلی Container دو موضوع جدا هستند. ابتدا بررسی کنید آیا برنامه واقعاً به IP ثابت Container وابسته شده است یا نه.

چرا Docker بعد از تغییر IP بالا است ولی سایت باز نمی‌شود؟

یکی از دلایل رایج باقی‌ماندن IP قبلی در Port Mapping، DNS، Nginx، Traefik، Caddy یا فایل Environment برنامه است. ابتدا docker ps و رکورد DNS دامنه را بررسی کنید.

آیا Restart کردن Docker مشکل تغییر IP را حل می‌کند؟

اگر مشکل فقط به بازسازی Ruleهای شبکه مربوط باشد ممکن است مؤثر باشد، اما اگر IP قبلی در Compose یا تنظیمات برنامه نوشته شده باشد Restart به‌تنهایی مشکل را حل نمی‌کند.

چرا Container به اینترنت وصل نمی‌شود ولی خود سرور اینترنت دارد؟

در این حالت باید NAT، IP Forwarding، Firewall و DNS مربوط به Docker بررسی شوند. ابتدا اتصال به یک IP عمومی را از Container آزمایش کنید و سپس DNS را جداگانه تست کنید.

آیا می‌توان IP را از بخش ports در Docker Compose حذف کرد؟

اگر منظور حذف Host IP از عبارتی مانند 192.0.2.10:8080:80 و تبدیل آن به 8080:80 است، از نظر Docker امکان‌پذیر است؛ اما در این حالت Port معمولاً روی Interfaceهای میزبان منتشر می‌شود. برای سرویس حساس باید پیامد امنیتی آن را بررسی کنید.

برای ارتباط بین Containerها IP بهتر است یا نام سرویس؟

در Docker Compose معمولاً نام سرویس انتخاب مناسب‌تری است؛ زیرا Container پس از ایجاد مجدد ممکن است IP داخلی متفاوتی بگیرد، ولی نام سرویس برای Service Discovery باقی می‌ماند.

منابع رسمی

🔹 مستندات رسمی Docker درباره Port Publishing و Binding

🔹 مستندات شبکه در Docker Compose

🔹 مستندات Docker درباره Firewall و Packet Filtering