Docker · فصل ۰۷Docker · Chapter 7

شبکه: bridge، DNS داخلی و publish

Networking: bridge networks, internal DNS, and port publishing

دو تا container داریم و هر دو Running هستند. حالا چطور یکی باید دیگری را پیدا کند؟ جواب از localhost شروع نمی‌شود؛ باید caller، شبکه و port درست را پیدا کنیم.

We have two running containers. How does one find the other? The answer does not start with localhost; it starts by finding the caller, the network, and the right port.

۱۲۰دقیقهٔ مطالعه و اجراminutes

۱۸تمرین با پاسخsolved exercises

۴نمودار مفهومیdiagrams

۱آزمایشگاه کاملfull lab

داده ماند؛ حالا web چطور پایگاه‌داده را پیدا کند؟The data stayed; how does web find the database?

فصل قبل پایگاه‌داده‌مان را از عمر container جدا کردیم. حالا یک web داریم و یک پایگاه‌داده؛ هر دو هم Running هستند. سؤال بعدی خیلی طبیعی است: web آدرس پایگاه‌داده را چه بنویسد؟ اولین چیزی که خیلی‌ها امتحان می‌کنند localhost است. بیایید اول همین حدس را خراب کنیم.

In Chapter 6 we separated data from the container lifetime. Now take a more realistic step: one container runs the web app and another runs the database. Both are up, but web must reach the database. The natural first guess is: “Should I use localhost?”

Experiment A · localhost from the wrong place

$ docker network create demo-net
demo-net

$ docker run -d --name web --network demo-net nginx:alpine
...

$ docker run --rm --network demo-net curlimages/curl:latest \
  -fsS --max-time 2 http://localhost
curl: (7) Failed to connect to localhost port 80 after 0 ms: Couldn't connect to server

$ docker run --rm --network demo-net curlimages/curl:latest \
  -fsS http://web | head -n 2
<!DOCTYPE html>
<html>

هر دو دستور از داخل یک container موقت اجرا می‌شوند. وقتی آنجا می‌نویسی localhost، در واقع داری به همان container موقت اشاره می‌کنی؛ Nginx داخل container دیگری به نام web است. وقتی به http://web می‌روی، این بار نامِ container مقصد را روی شبکهٔ مشترک استفاده کرده‌ای.

Both commands ran from a temporary client container. In the first command, localhost means the loopback of that client; nginx is not inside the client. In the second, web is the container name on demo-net, and Docker resolves it to web's internal address.

مدل ذهنی اصلیThe main mental model

قاعده‌ای که کل فصل روی آن می‌ایستد همین است: localhost یعنی «همین‌جایی که من هستم». از روی host یعنی خود host؛ داخل web یعنی خود web؛ داخل client یعنی خود client. localhost هیچ‌وقت اسم مستعار «بقیهٔ containerها» نیست.

localhost means “this network namespace where the command runs.” From the host it is the host; from web it is web; from client it is client.

یک localhost، چند «همین‌جا»Three localhosts: one word, several scopes

فعلاً لازم نیست وارد جزئیات kernel شویم. هر container را مثل یک اتاق کوچک شبکه تصور کن؛ loopback، interface و دید خودش را دارد. Docker می‌تواند بین این اتاق‌ها راه بسازد، اما localhost همیشه داخل همان اتاق می‌ماند. همین تصویر ساده بعداً خیلی از خطاهای شبکه را توضیح می‌دهد.

You do not need kernel details at the start. For this chapter, think of a network namespace as a network room: each container has its own loopback, interface, routes, and DNS view. Docker can connect those rooms with interfaces and a bridge, but localhost does not cross a room's wall.

کادرها سه محدوده مستقل را نشان می‌دهند، نه سه اسم برای یک آدرس. فلش host به web فقط مسیر publish شده را معنا می‌کند؛ فلش client به web مسیر شبکه داخلی را نشان می‌دهد. هیچ‌کدام localhost را به اتاق دیگری منتقل نمی‌کنند.

The boxes show three independent scopes, not three names for one address. The host-to-web arrow means a published path; the client-to-web arrow means an internal network path. Neither changes what localhost means inside another room.

پس قبل از اینکه port را عوض کنی، یک سؤال خیلی ساده بپرس: «این دستور دقیقاً از کجا اجرا شده؟» اگر از client اجرا شده، localhost:80 فقط دنبال سرویس داخل همان client می‌گردد. برای رسیدن به web باید واقعاً راهی بین دو container وجود داشته باشد و مقصد را هم درست صدا بزنی.

When you see a failure, ask where the command ran before changing ports. If it ran in client, localhost:80 needs a service inside that client. To reach web, you need a path between the containers and a destination name or address.

bridge چیست؟ یک شبکهٔ مشترک با درِ مشخصWhat is a bridge? A shared network with a clear boundary

حالا باید بین این «اتاق‌ها» یک راه مشترک بسازیم. bridge شبکه را می‌توانی مثل یک شبکهٔ محلی نرم‌افزاری ببینی: containerهایی که عضو آن هستند interface و آدرس می‌گیرند و می‌توانند به سرویس‌های هم دسترسی داشته باشند. container بیرون این شبکه، چنین مسیر داخلی‌ای را خودکار ندارد.

When containers join a bridge network, Docker gives each one an interface and an address from that network's subnet. A bridge is a software local network: members can reach one another's ports, while containers on other networks do not normally have that internal path.

Docker از اول یک شبکهٔ bridge پیش‌فرض دارد. برای آزمایش‌های ساده بد نیست، اما وقتی چند سرویس متعلق به یک برنامه داری بهتر است شبکهٔ خودت را نام‌گذاری کنی؛ مثلاً demo-net. آن‌وقت دقیقاً معلوم است چه containerهایی عضو این مجموعه‌اند و نام‌ها در کدام شبکه معنی دارند.

Separate two bridge cases. Docker Engine creates the default bridge network, and a container without --network normally joins it. A user-defined bridge is one you create with docker network create and name for an application stack.

ویژگی	default `bridge`	user-defined bridge
ورود container	پیش‌فرض، اگر network ندهی	با `--network NAME` یا `network connect`
پیداکردن با نام	automatic DNS برای container name ندارد؛ link قدیمی است	automatic DNS با name یا alias همان network
مرزبندی stack	containerهای بی‌ربط هم در یک network مشترک‌اند	فقط اعضای متصل به همان network در scope هستند
اتصال در طول عمر	مدیریت محدودتر و legacy	`connect` و `disconnect` بدون recreate
انتخاب عملی	برای آزمایش ساده یا سازگاری قدیمی	انتخاب معمول برای applicationهای چندcontainerی

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

“Better” does not mean automatically secure. A user-defined bridge gives a better scope and name-resolution model; you still choose published ports, credentials, and service access deliberately.

یک شبکه بساز و نام را به‌جای IP به‌کار ببرCreate a network and use the name instead of the IP

آدرس IP داخلی container چیزی نیست که بخواهی داخل تنظیمات برنامه حک کنی. ممکن است web را حذف و دوباره بسازی و IP عوض شود. اسم web روی شبکهٔ خودت قرارداد بهتری است: برنامه مقصد را با نام می‌شناسد و Docker آدرس فعلی را پیدا می‌کند.

When web is recreated, its internal IP may change. If the application config contains that IP, every recreate becomes a small incident. A container name on a user-defined network is a more stable contract for this purpose.

create · attach · resolve

$ docker network create --driver bridge demo-net
demo-net

$ docker network ls
NETWORK ID     NAME       DRIVER    SCOPE
...            bridge     bridge    local
...            demo-net   bridge    local

$ docker run -d --name web --network demo-net nginx:alpine
...

$ docker run --rm --network demo-net curlimages/curl:latest   -fsS -v http://web

# representative lines from curl
* Connected to web (...) port 80
< HTTP/1.1 200 OK

در خروجی curl -v خطی شبیه Connected to web را پیدا کن. نکته همین است: ما IP را ننوشته‌ایم. client نام web را در همان شبکه پیدا کرده و بعد درخواست HTTP را به آدرس فعلی آن فرستاده است.

In PowerShell, Select-String only shortens the displayed output; on Linux or macOS use grep -E 'Connected|HTTP/'. The useful line is Connected to web: client resolved web to an IP without us memorizing that IP.

در نمودار دو اتفاق جدا داریم. اول نام web به آدرس داخلی فعلی‌اش پیدا می‌شود؛ بعد درخواست HTTP به port 80 آن آدرس می‌رود. جدا دیدن این دو مرحله مهم است، چون «نام پیدا نشد» با «نام پیدا شد ولی اتصال رد شد» دو مشکل متفاوت‌اند.

The first arrow is only name resolution: web becomes an internal address within demo-net. The second arrow is the actual HTTP request to web's port 80; keep the two steps distinct.

این نام جادویی و global نیست. اگر client را از demo-net جدا کنی، دیگر همان DNS محدوده را ندارد و web پیدا نمی‌شود یا مسیرش در دسترس نیست. همین وابستگی به عضویت دلیل خوبی است که اسم شبکه را در کنار سرویس‌ها مدیریت کنی.

This name is not magical or global. Disconnect client from demo-net and it no longer has that DNS scope or path to web. That membership dependency is why the network name belongs in the service setup.

وقتی ارتباط قطع شد، خود شبکه را نگاه کنWhat does network inspect show?

وقتی client به web نمی‌رسد، حدس‌زدن IP آخرین کاری است که می‌خواهیم بکنیم. خود demo-net را inspect کن. آنجا می‌بینی شبکه چه اسمی دارد، driver چیست و کدام containerها واقعاً عضو آن هستند. خیلی وقت‌ها مشکل همین است که یکی از دو طرف اصلاً روی شبکه‌ای که فکر می‌کردی نیست.

When “client cannot reach web,” inspect the network instead of guessing an IP. The network name, driver, subnet, gateway, and connected containers appear together in this output.

representative network inspect · addresses vary

$ docker network inspect demo-net
[
  {
    "Name": "demo-net",
    "Driver": "bridge",
    "Scope": "local",
    "IPAM": {
      "Config": [{ "Subnet": "172.19.0.0/16", "Gateway": "172.19.0.1" }]
    },
    "Containers": {
      "a1b2...": {
        "Name": "web",
        "IPv4Address": "172.19.0.2/16"
      }
    }
  }
]

خروجی را با سه سؤال بخوان: آیا شبکهٔ درست را نگاه می‌کنم؟ آیا web واقعاً در فهرست اعضاست؟ آیا آدرسی گرفته؟ IP برای عیب‌یابی خوب است، ولی آن را تبدیل به تنظیم دائمی برنامه نکن؛ اسم سرویس برای همین ساخته شده است.

Use the output to answer three questions: did I inspect the right network name? Is web actually listed under Containers? Do the address and subnet match the situation? The IP is useful for diagnosis, but should not become permanent application configuration.

برای دیدن اتصال‌های خود container هم docker inspect web --format '{{json .NetworkSettings.Networks}}' بزن. این دو inspect مکمل‌اند: یکی از دید شبکه حرف می‌زند، دیگری از دید container.

To see a container's own attachments, run docker inspect web --format '{{json .NetworkSettings.Networks}}'. The two inspections complement each other: one speaks from the network's view, the other from the container's view.

port داخلی با port روی host یکی نیستAn internal port is not a host port

Nginx داخل web روی port 80 گوش می‌دهد. اگر client روی همان شبکه باشد، می‌تواند مستقیم به web:80 برود؛ این مسیر اصلاً لازم نیست از portهای host عبور کند. این همان جایی است که مفهوم شبکهٔ داخلی با publish از هم جدا می‌شود.

nginx listens on port 80 inside web. That port belongs to web's world. When client on the same network requests http://web:80, it reaches the internal port directly and needs no -p.

مرورگر تو روی host عضو demo-net نیست. اگر می‌خواهی از localhost:8080 وارد Nginx شوی، باید یک در روی host باز کنی: -p 8080:80. سمت چپ دری است که روی host می‌زنی؛ سمت راست port سرویس داخل container است.

A browser on the host is not a member of demo-net. To let the host enter through localhost:8080, you need a mapping: -p 8080:80. The left number is the host port; the right number is the container port.

caller	آدرس مقصد	`-p` لازم است؟	مسیر request
client روی `demo-net`	`http://web:80`	نه	client → bridge → web:80
browser روی host	`http://localhost:8080`	بله، `8080:80`	host:8080 → mapping → web:80
container روی network دیگر	`http://web:80`	برای internal path کافی نیست	باید network مشترک یا مسیر دیگری داشته باشد

host port collision · same host port twice

$ docker run -d --name web-copy --network demo-net \
  -p 127.0.0.1:8080:80 nginx:alpine
docker: Error response from daemon: driver failed programming external connectivity
on endpoint web-copy (...): Bind for 127.0.0.1:8080 failed: port is already allocated.

این خطا دربارهٔ port داخلی nginx نیست؛ host port ۸۰۸۰ قبلاً مالک دارد. اول docker ps و نگاشت را پیدا کن، بعد host port را عوض کن یا اگر caller داخلی است اصلاً publish را حذف کن.

This failure is not about nginx's internal port; host port 8080 is already owned. Find the existing mapping with docker ps, then change the host port or remove publishing if the caller is internal.

هر فلش درخواست مسیر را نشان می‌دهد. publish یک درِ host می‌سازد؛ port داخلی عوض نمی‌شود و nginx هنوز روی ۸۰ است. مسیر داخلی client به web از این نگاشت عبور نمی‌کند.

Each arrow is a request path. Publishing creates a host-side door; the internal port does not change and nginx still listens on 80. The internal client-to-web path does not need to cross this mapping.

در اجرای امن‌ترِ محلی می‌توانی host IP را هم صریح بدهی: -p 127.0.0.1:8080:80. اگر IP host را ندهی، Docker معمولاً port را روی interfaceهای host منتشر می‌کند؛ پس publish را با «فقط برای مرورگر خودم» یکی ندان.

For a safer local run, bind the host address explicitly: -p 127.0.0.1:8080:80. Without a host IP, Docker normally publishes on the host interfaces, so “published” does not automatically mean “only for my browser.”

یک بار web را بدون publish و بار دوم با publish اجرا کنRun web once without publishing, then with publishing

حالا این دو مسیر را کنار هم ببین. بار اول Nginx فقط عضو شبکهٔ داخلی است: client باید به web:80 برسد، ولی host هنوز دری روی 8080 ندارد. بار دوم همان web را با -p می‌سازیم؛ چیزی در ارتباط داخلی عوض نشده، فقط یک مسیر تازه از host به container اضافه شده است.

This experiment puts the two traffic paths side by side. First web is only a network member. client should succeed, while host localhost:8080 should not reach this web. Then we recreate web and add one host mapping.

internal path versus host path

$ docker run --rm --network demo-net curlimages/curl:latest -fsS http://web:80 > $null
$LASTEXITCODE
0

# Run on the host; choose a free host port for this experiment.
PS> curl.exe --fail --max-time 2 http://127.0.0.1:8080
curl: (7) Failed to connect to 127.0.0.1 port 8080

$ docker rm -f web
web

$ docker run -d --name web --network demo-net \
  -p 127.0.0.1:8080:80 nginx:alpine
...

PS> curl.exe --fail http://127.0.0.1:8080 | Select-Object -First 1
<!DOCTYPE html>

$ docker port web
80/tcp -> 127.0.0.1:8080

اگر client قبل از publish هم به web می‌رسد، یعنی ارتباط داخلی به -p وابسته نیست. publish فقط برای callerای لازم است که بیرون آن شبکه است—مثل مرورگر روی host. اگر 8080 روی سیستم تو اشغال است، عدد دیگری انتخاب کن؛ مفهوم عوض نمی‌شود.

The first line proves internal traffic does not depend on publishing. The second only tests host localhost:8080; another process may already own that port, so choose a free one on your machine. After recreation, client still uses http://web:80 and the host browser has the new path.

EXPOSE همان publish نیستEXPOSE is not publish

EXPOSE 80 در Dockerfile فقط قرارداد/metadata دربارهٔ port مورد انتظار image است. دسترسی host با -p ساخته می‌شود؛ و دسترسی containerهای روی شبکه مشترک به‌طور معمول به -p نیاز ندارد.

EXPOSE 80 in a Dockerfile is a contract or metadata about the image's expected port. Host access is created with -p; containers on the same network normally do not need -p for their internal path.

default bridge چه کم دارد؟What is missing from the default bridge?

شبکهٔ پیش‌فرض Docker خراب یا ممنوع نیست؛ برای آزمایش ساده کار می‌کند. مشکل این است که وقتی یک برنامه چند سرویس دارد، نام‌گذاری و مرزبندی روشن می‌خواهی. شبکهٔ نام‌دار خودت این رابطه را واضح‌تر می‌کند و پیدا کردن containerها با نام را هم ساده می‌کند.

The default bridge is not necessarily “broken.” It is useful for quick experiments, and containers on it can communicate through internal IPs. The problem appears when you need service names, stack boundaries, and attach/detach behavior during a container's lifetime.

the legacy name-resolution surprise

$ docker run -d --name legacy-web nginx:alpine
...

$ docker run --rm --network bridge curlimages/curl:latest \
  -fsS --max-time 2 http://legacy-web
curl: (6) Could not resolve host: legacy-web

# The same container's IP may work on the default bridge,
# but that IP is not a stable application name.

این رفتار با user-defined bridge فرق دارد: آنجا Docker embedded DNS نام container یا alias را در همان شبکه پاسخ می‌دهد. به همین دلیل برای web و پایگاه‌داده یک شبکه نام‌دار بساز؛ به link قدیمی یا نوشتن IP در تنظیمات برنگرد.

This differs from a user-defined bridge, where Docker's embedded DNS resolves a container name or alias on that network. That is why you create a named network for web and database instead of returning to legacy links or putting an IP in application config.

container را به شبکه وصل و جدا کنConnect and disconnect a container

اگر container از قبل روشن است، برای اضافه‌کردنش به یک شبکه لازم نیست حذفش کنی. docker network connect یک اتصال شبکهٔ تازه به همان container اضافه می‌کند و disconnect همان اتصال را برمی‌دارد. اینجا دقیقاً می‌توانی ببینی «عضویت در شبکه» یک ویژگی مستقل از خودِ روشن‌بودن container است.

When you create a container with --network, the attachment exists from the start. If a container is already running, you do not need to remove it to add a user-defined network; docker network connect adds another interface.

attach, observe, detach

$ docker network create side-net
side-net

$ docker run -d --name helper alpine sleep 3600
...

$ docker network connect side-net helper

$ docker network inspect side-net
...
"Name": "helper",
"IPv4Address": "172.20.0.2/16"

$ docker network disconnect side-net helper

$ docker network inspect side-net
"Containers": {}

attach شدن یعنی کمکی حالا یک نقطهٔ اتصال در side-net دارد؛ detach شدن همان نقطهٔ اتصال را برمی‌دارد. اگر کمکی تنها شبکه خود را از دست بدهد، commandهای بعدی‌اش فقط loopback را می‌بینند و برای ارتباط شبکه‌ای شکست می‌خورند.

Connecting means helper now has an endpoint in side-net; disconnecting removes that endpoint. If helper loses its only network, later commands see only loopback and network requests fail.

یک container می‌تواند روی دو شبکه باشدOne container can belong to two networks

یک برنامهٔ واقعی همیشه یک شبکه ندارد. شاید web روی شبکهٔ جلویی باشد، پایگاه‌داده روی شبکهٔ پشتی و یک gateway لازم باشد هر دو طرف را ببیند. قرار نیست برای راحتی همه را به همه‌جا وصل کنیم؛ هر container فقط شبکه‌هایی را می‌گیرد که واقعاً لازم دارد.

A more realistic setup has web on front-net, database on back-net, and a gateway or worker that needs both. That dual attachment should not make every container see everything.

فلش‌های افقی درخواست را نشان می‌دهند و فلش عمودی attachment را: gateway در هر دو شبکه عضو است، اما web و db فقط در محدوده خودشان هستند. همین عضویت تعیین می‌کند کدام نام قابل پیدا و کدام مسیر قابل استفاده باشد.

The horizontal arrows are request paths and the vertical arrow is an attachment. The gateway belongs to both networks, while web and db stay in their own scopes. Membership determines which names resolve and which paths exist.

isolation experiment

$ docker network create front-net
front-net
$ docker network create back-net
back-net

$ docker run -d --name web-front --network front-net nginx:alpine
...
$ docker run -d --name db-back --network back-net nginx:alpine
...

$ docker run --rm --network front-net curlimages/curl:latest \
  -fsS --max-time 2 http://db-back
curl: (6) Could not resolve host: db-back

$ docker network connect front-net db-back

$ docker run --rm --network front-net curlimages/curl:latest \
  -fsS http://db-back | Select-Object -First 1
<!DOCTYPE html>

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

Here db-back belongs to both networks after connect, so a client on front-net can resolve it. This is not a complete security boundary; it is a practical path boundary. Use separate networks and limited membership for a clearer scope.

وقتی «شبکه کار نمی‌کند»، مسیر درخواست را قدم‌به‌قدم دنبال کنDebug from the request path

«شبکه کار نمی‌کند» تقریباً هیچ اطلاعاتی به ما نمی‌دهد. اول بپرس درخواست از کجا شروع شده، چه نامی را صدا زده، دو container عضو چه شبکه‌ای هستند و برنامه روی کدام port گوش می‌دهد. همین چند سؤال معمولاً مشکل را از یک مه غلیظ به یک نقطهٔ مشخص تبدیل می‌کند.

“The network does not work” is not yet a solvable problem. Turn the request into smaller questions: who is the caller? Where does it run? Which name or address does it use? Which networks attach the two containers? Which port is the service actually listening on? Is this internal traffic or host-to-container?

نشانه	مسیر محتمل خراب	اول چه چیزی را بررسی کن؟
`curl http://localhost` از client fail می‌شود	caller را به مقصد اشتباه گرفته‌ای	`localhost` همان client است؛ name واقعی web را امتحان کن
name resolve نمی‌شود	name اشتباه است یا caller در network مشترک نیست	`docker network inspect` و spelling name/alias
containerها networkهای متفاوت دارند	DNS scope و path مشترک ندارند	هر دو را به user-defined network مشترک وصل کن یا مسیر طراحی‌شده بده
port host قبلاً گرفته شده	دو mapping یک HOST_PORT می‌خواهند	`docker ps` و port آزاد؛ host port را عوض کن
`-p 80:8080` جواب نمی‌دهد	جهت mapping برعکس یا internal port غلط است	چپ host، راست container؛ port واقعی listen را inspect کن
service فقط روی `127.0.0.1` گوش می‌دهد	از interface شبکهٔ container قابل رسیدن نیست	برای service بین containerها معمولاً `0.0.0.0` یا interface مناسب لازم است
بعد از recreate آدرس عوض شده	IP را به‌عنوان config پایدار نگه داشته‌ای	در user-defined network با name سرویس کار کن
client از host port داخلی را می‌زند	internal traffic را از publish برگردانده‌ای	روی network مشترک مستقیم `http://web:80` بزن

name resolves, port is wrong

$ docker run --rm --network demo-net curlimages/curl:latest \
  -fsS --max-time 2 http://web:8080
curl: (7) Failed to connect to web port 8080: Couldn't connect to server

# The same service answers on its internal port:
$ docker run --rm --network demo-net curlimages/curl:latest \
  -fsS http://web:80 | Select-Object -First 1
<!DOCTYPE html>

در اینجا نام درست پیدا شده، اما port مقصد با سرویس گوش‌دهنده یکی نیست. این خطا از «Could not پیدا host» یک مرحله جلوتر است: DNS کار کرده و حالا باید port و bind آدرس را بررسی کنی.

Here the name resolved, but the destination port does not match the listener. This is one step past “Could not resolve host”: DNS worked, so now inspect the port and bind address.

دو خطا را از هم جدا کن. اگر نام پیدا نمی‌شود، هنوز به مرحلهٔ اتصال نرسیده‌ای؛ عضویت شبکه و DNS را نگاه کن. اگر نام پیدا می‌شود ولی connection refused می‌گیری، یک قدم جلوتر رفته‌ای: مقصد پیدا شده، اما روی آن port سرویسی گوش نمی‌دهد یا مسیر port اشتباه است.

Keep two nearby failures separate: “name not found” usually happens before a TCP connection; “connection refused” means the destination resolved but no listener or correct mapping exists there. That distinction changes the diagnosis path.

تمرین‌ها: قبل از تغییر دستور، مسیر را حدس بزنExercises: predict the path before changing the command

تمرین‌ها را با حفظ‌کردن دستور حل نکن. برای هر سناریو اول روی کاغذ چهار چیز بنویس: درخواست از کجا می‌آید؟ مقصد چه اسمی دارد؟ هر طرف عضو کدام شبکه است؟ port داخلی یا host port کدام است؟ وقتی این چهار مورد روشن شد، دستور تقریباً خودش معلوم می‌شود.

These exercises are not syntax memorization. For each one, name the caller, network, destination name, and port before choosing a command or diagnosis.

۱. localhost از کجا می‌آید؟1. Where does localhost come from?

web و client روی demo-net هستند. اگر داخل client به http://localhost:80 curl بزنی، انتظار موفقیت داری یا شکست؟

web and client are on demo-net. If curl inside client requests http://localhost:80, do you expect success or failure?