[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$ffyH7tD_5USlB0wwO31McjASO6V5_BDzFFqlhJBBLQd4":3},{"data":4,"related":90},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":63,"faqs":76,"related_services":86,"comments_enabled":88,"meta_title":19,"meta_description":89,"canonical_url":19,"noindex":27,"is_live":88},14,"SSH وصل است ولی scp هنگ می‌کند؛ راز MTU در مهاجرت ابری","cloud-migration-mtu-scp-hangs","بعد از مهاجرت سرور به ابر، SSH وصل می‌شود اما scp و rsync وسط انتقال هنگ می‌کنند. ریشه ماجرا MTU کوچک‌تر شبکه overlay و مسدود بودن ICMP برای PMTUD است.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F0d69eee7-4386-48c9-a8a3-17eaeb78c5b5.webp",{"name":12,"slug":13},"زیرساخت ابری و IaC","cloud-infrastructure",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",5,false,"2026-10-16T09:49:00+00:00","\u003Cp>یکی از آزاردهنده‌ترین سناریوها در مهاجرت ابری این است: سرور را از دیتاسنتر داخلی به ابر منتقل می‌کنی، SSH وصل می‌شود، پینگ جواب می‌دهد، اما به‌محض اینکه یک انتقال داده‌ی واقعی شروع می‌شود همه‌چیز هنگ می‌کند. خطای واضحی هم نمی‌بینی؛ فقط بی‌صدا می‌میرد. در این مقاله علت این رفتار را می‌شکافیم و راه‌حل عملی و پایدارش را می‌بینیم.\u003C\u002Fp>\u003Ch2 id=\"شرح-مسئله-کوچک‌ها-رد-می‌شوند-بزرگ‌ها-گم-می‌شوند\">شرح مسئله: کوچک‌ها رد می‌شوند، بزرگ‌ها گم می‌شوند\u003C\u002Fh2>\u003Cp>نشانه‌ها معمولاً این‌گونه ظاهر می‌شوند:\u003C\u002Fp>\u003Cul>\u003Cli>اتصال SSH باز می‌شود، تایپ روان است و لاگ‌ها را می‌خوانی؛ چون بسته‌های کوچک مشکلی ندارند.\u003C\u002Fli>\u003Cli>دستور \u003Ccode>scp\u003C\u002Fcode> یا \u003Ccode>rsync\u003C\u002Fcode> شروع می‌کند، چند درصد جلو می‌رود و بعد کاملاً فریز می‌شود؛ حتی تایم‌اوت هم ممکن است بدهد.\u003C\u002Fli>\u003Cli>دستور \u003Ccode>git clone\u003C\u002Fcode> روی مخزن بزرگ وسط کار گیر می‌کند.\u003C\u002Fli>\u003Cli>درخواست‌های \u003Ccode>curl https:\u002F\u002F...\u003C\u002Fcode> که پاسخ حجیم دارند، با خطای زیر می‌میرند:\u003C\u002Fli>\u003C\u002Ful>\u003Cpre>\u003Ccode class=\"language-bash\">$ curl -v https:\u002F\u002Fexample.com\u002Flarge-file\n* Connected to example.com (203.0.113.10) port 443\n* TLS handshake in progress...\ncurl: (28) SSL connection timeout\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>و در انتقال فایل عملاً این‌طور می‌شود:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">$ scp bigfile.tar.gz user@server:\u002Ftmp\u002F\nbigfile.tar.gz        12%  512MB   1.2MB\u002Fs   eta 8m 12s\npacket_write_wait: Connection to server port 22: Broken pipe\nlost connection\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>نکته‌ی کلیدی این است که پینگ ساده (که بسته‌ی کوچک می‌فرستد) سالم است و همین موضوع گمراهت می‌کند. مشکل فقط روی بسته‌های بزرگ‌تر از یک اندازه‌ی خاص ظاهر می‌شود.\u003C\u002Fp>\u003Ch2 id=\"علت-ریشه‌ای-mtu-کوچک‌تر-و-icmp-مسدود\">علت ریشه‌ای: MTU کوچک‌تر و ICMP مسدود\u003C\u002Fh2>\u003Cp>در دیتاسنتر داخلی، MTU شبکه تقریباً همیشه ۱۵۰۰ بایت است. اما در ابر، ترافیک VM از لایه‌های کپسوله‌سازی عبور می‌کند؛ VXLAN، Geneve یا GENEVE-based overlayها روی بسته‌ی اصلی یک هدر اضافه می‌کنند. نتیجه این است که MTU مؤثر مسیر معمولاً بین ۱۴۰۰ تا ۱۴۵۰ بایت می‌شود، نه ۱۵۰۰.\u003C\u002Fp>\u003Cp>حالا ماشینی که از دیتاسنتر آمده، اینترفیسش هنوز MTU=1500 اعلام می‌کند. برای بسته‌های کوچک (مثل دست‌دادن SSH یا کلیدهای فشرده) مشکلی نیست. اما وقتی یک بسته‌ی ۱۵۰۰ بایتی با فلگ DF (Don't Fragment) فرستاده می‌شود، در گلوگاه overlay دیگر جا نمی‌شود. اینجا باید ICMP «Fragmentation Needed» برگردد تا مبدأ اندازه را کم کند (همان PMTUD). اما اکثر پلتفرم‌های ابری ICMP را در مسیر فیلتر یا rate-limit می‌کنند؛ پس بسته بی‌صدا drop می‌شود و مبدأ هیچ‌وقت نمی‌فهمد.\u003C\u002Fp>\u003Cp>این پدیده Black Hole است: TCP دوباره و دوباره تلاش می‌کند، `ss -i` پر از retransmit می‌شود و اتصال در نهایت می‌میرد. چون بسته‌های SYN و handshake کوچک‌اند، اتصال اولشه برقرار می‌شود؛ درست همان «SSH کار می‌کند ولی scp نه».\u003C\u002Fp>\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\u003Ch3 id=\"گام-۱-دیدن-mtu-فعلی\">گام ۱: دیدن MTU فعلی\u003C\u002Fh3>\u003Cp>اول ببین اینترفیس اصلی چه MTUای دارد و نامش چیست (در ابر معمولاً ens3 یا eth0):\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">ip -br link show\nip link show ens3 | grep mtu\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>اگر عدد ۱۵۰۰ دیدی و مقصدت ابری است، مشکوک شو.\u003C\u002Fp>\u003Ch3 id=\"گام-۲-پیدا-کردن-mtu-واقعی-مسیر-با-ping\">گام ۲: پیدا کردن MTU واقعی مسیر با ping\u003C\u002Fh3>\u003Cp>ابزار \u003Ccode>ping\u003C\u002Fcode> با فلگ \u003Ccode>-M do\u003C\u002Fcode> اجازه‌ی fragmentation نمی‌دهد و اندازه‌ی payload را با \u003Ccode>-s\u003C\u002Fcode> تعیین می‌کنیم. یادت باشد 28 بایت هدر IP+ICMP روی payload می‌آید؛ پس برای MTU=1500 باید 1472 بفرستی.\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\"># MTU 1500 → payload 1472\nping -M do -s 1472 8.8.8.8\n\n# اگر شکست خورد، تدریجی کم کن\nping -M do -s 1422 8.8.8.8   # MTU 1450\nping -M do -s 1372 8.8.8.8   # MTU 1400\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>اگر ICMP بیرونی مسدود بود، پینگ را به گیت‌وی پیش‌فرض بزن که همیشه در دسترس است:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">ip route show default\nping -M do -s 1472 10.0.0.1\nping -M do -s 1372 10.0.0.1\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>برای دیدن سریع PMTU هم می‌توانی از \u003Ccode>tracepath\u003C\u002Fcode> استفاده کنی:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">tracepath -n 8.8.8.8\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>بزرگ‌ترین اندازه‌ای که بدون خطا رد می‌شود، MTU واقعی مسیر را به تو می‌دهد.\u003C\u002Fp>\u003Ch3 id=\"گام-۳-اعمال-موقت-روی-اینترفیس\">گام ۳: اعمال موقت روی اینترفیس\u003C\u002Fh3>\u003Cpre>\u003Ccode class=\"language-bash\">sudo ip link set dev ens3 mtu 1400\nip link show ens3 | grep mtu\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>بلافاصله بعد از این دستور، دوباره \u003Ccode>scp\u003C\u002Fcode> را تست کن. اگر روان شد، علت تأیید شده است. این تغییر موقتی است و با ری‌استارت از دست می‌رود.\u003C\u002Fp>\u003Ch3 id=\"گام-۴-پایدارسازی-پیکربندی\">گام ۴: پایدارسازی پیکربندی\u003C\u002Fh3>\u003Cp>روی Ubuntu با netplan فایل \u003Ccode>\u002Fetc\u002Fnetplan\u002F01-netcfg.yaml\u003C\u002Fcode> را ویرایش کن:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-yaml\">network:\n  version: 2\n  ethernets:\n    ens3:\n      dhcp4: true\n      mtu: 1400\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>و اعمال کن:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">sudo netplan apply\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>اگر از NetworkManager استفاده می‌کنی:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">nmcli connection show\nsudo nmcli connection modify \"Wired connection 1\" 802-3-ethernet.mtu 1400\nsudo nmcli connection up \"Wired connection 1\"\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>روی خانواده‌ی RHEL با ifcfg، در فایل \u003Ccode>\u002Fetc\u002Fsysconfig\u002Fnetwork-scripts\u002Fifcfg-ens3\u003C\u002Fcode> خط زیر را اضافه کن:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-ini\">MTU=1400\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>و سپس:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">sudo nmcli connection reload\nsudo nmcli connection up ens3\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch3 id=\"گام-۵-کلپ-کردن-mss-اگر-گیت‌وی-دست-خودت-است\">گام ۵: کلپ کردن MSS (اگر گیت‌وی دست خودت است)\u003C\u002Fh3>\u003Cp>اگر این ماشین نقش روتر یا گیت‌وی داخلی را دارد و ترافیک را forward می‌کند، بهتر است MSS را هم clamp کنی تا کلاینت‌ها ایمن بمانند. مقدار MSS برابر MTU منهای 40 بایت (هدر IP و TCP) است؛ برای MTU=1400 می‌شود 1360:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \\\n  -j TCPMSS --clamp-mss-to-pmtu\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>روی خود سرور هم می‌توانی روی خروجی تنظیم کنی:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">sudo iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \\\n  -j TCPMSS --set-mss 1360\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch2 id=\"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است\">چطور مطمئن شویم مشکل واقعاً حل شده است\u003C\u002Fh2>\u003Cul>\u003Cli>دوباره تست پینگ بزرگ: \u003Ccode>ping -M do -s 1372 8.8.8.8\u003C\u002Fcode> باید بدون خطا جواب دهد.\u003C\u002Fli>\u003Cli>یک فایل چند صد مگابایتی را با \u003Ccode>scp\u003C\u002Fcode> منتقل کن و مطمئن شو سرعت پایدار است و قطع نمی‌شود.\u003C\u002Fli>\u003Cli>در حین انتقال، در یک ترمینال دیگر این را بزن؛ MSS باید حدود ۱۳۶۰ باشد و retransmit بالا نباشد:\u003C\u002Fli>\u003C\u002Ful>\u003Cpre>\u003Ccode class=\"language-bash\">ss -i -t state established\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cul>\u003Cli>شمارنده‌های retransmit را چک کن؛ باید در بازه‌ی کوتاه تقریباً صفر بمانند:\u003C\u002Fli>\u003C\u002Ful>\u003Cpre>\u003Ccode class=\"language-bash\">netstat -s | grep -i -E 'retrans|timeout'\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>اگر انتقال بزرگ بدون قطعی تمام شد و MSS درست گزارش شد، مشکل حل شده است.\u003C\u002Fp>\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\u003Cul>\u003Cli>MTU را جزء چک‌لیست مهاجرت بگذار. قبل از تحویل سرور، یک تست \u003Ccode>ping -M do\u003C\u002Fcode> و یک انتقال بزرگ انجام بده.\u003C\u002Fli>\u003Cli>MTU را از روز اول در provisioning ست کن؛ مثلاً با cloud-init تا ماشین‌های جدید بدون دخالت دستی درست بالا بیایند:\u003C\u002Fli>\u003C\u002Ful>\u003Cpre>\u003Ccode class=\"language-yaml\">#cloud-config\nnetwork:\n  version: 2\n  ethernets:\n    ens3:\n      dhcp4: true\n      mtu: 1400\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cul>\u003Cli>مقدار MTU را بر اساس نوع شبکه‌ی ابری انتخاب کن؛ overlayهای VXLAN معمولاً MTU مؤثر ۱۴۵۰ و بعضی پیاده‌سازی‌ها ۱۴۰۰ می‌دهند. مقدار امن، کوچک‌ترین مقدار قابل قبول کل مسیر است.\u003C\u002Fli>\u003Cli>در گیت‌وی داخلی خودت، ICMP نوع ۳ کد ۴ را هرگز فیلتر نکن و MSS clamping را فعال نگه دار. PMTUD بدون ICMP کار نمی‌کند.\u003C\u002Fli>\u003Cli>شمارنده‌ی retransmit و timeout را در \u003Ca href=\"\u002Fservices\u002Fmonitoring\">مانیتورینگ\u003C\u002Fa> داشته باش؛ افزایش ناگهانی آن‌ها اولین زنگ خطر مشکل MTU است.\u003C\u002Fli>\u003C\u002Ful>\u003Cblockquote>قاعده‌ی طلایی مهاجرت ابری: اگر اتصال برقرار می‌شود ولی داده‌ی حجیم رد نمی‌شود، شک اولت به MTU باشد، نه فایروال و نه DNS.\u003C\u002Fblockquote>",[31,35,38,41,45,48,51,54,57,60],{"id":32,"text":33,"level":34},"شرح-مسئله-کوچک‌ها-رد-می‌شوند-بزرگ‌ها-گم-می‌شوند","شرح مسئله: کوچک‌ها رد می‌شوند، بزرگ‌ها گم می‌شوند",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای-mtu-کوچک‌تر-و-icmp-مسدود","علت ریشه‌ای: MTU کوچک‌تر و ICMP مسدود",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"گام-۱-دیدن-mtu-فعلی","گام ۱: دیدن MTU فعلی",3,{"id":46,"text":47,"level":44},"گام-۲-پیدا-کردن-mtu-واقعی-مسیر-با-ping","گام ۲: پیدا کردن MTU واقعی مسیر با ping",{"id":49,"text":50,"level":44},"گام-۳-اعمال-موقت-روی-اینترفیس","گام ۳: اعمال موقت روی اینترفیس",{"id":52,"text":53,"level":44},"گام-۴-پایدارسازی-پیکربندی","گام ۴: پایدارسازی پیکربندی",{"id":55,"text":56,"level":44},"گام-۵-کلپ-کردن-mss-اگر-گیت‌وی-دست-خودت-است","گام ۵: کلپ کردن MSS (اگر گیت‌وی دست خودت است)",{"id":58,"text":59,"level":34},"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است","چطور مطمئن شویم مشکل واقعاً حل شده است",{"id":61,"text":62,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[64,67,70,72,74],{"name":65,"slug":66},"Linux","linux",{"name":68,"slug":69},"Troubleshooting","troubleshooting",{"name":71,"slug":71},"cloud-migration",{"name":73,"slug":73},"networking",{"name":75,"slug":75},"mtu",[77,80,83],{"question":78,"answer":79},"چرا SSH کار می‌کند اما scp هنگ می‌کند؟","چون بسته‌های SSH در ابتدا کوچک‌اند و از MTU مسیر عبور می‌کنند، اما انتقال فایل بسته‌های بزرگ با فلگ DF می‌فرستد. اگر MTU مسیر کمتر از ۱۵۰۰ باشد و ICMP برای PMTUD مسدود باشد، این بسته‌ها بی‌صدا drop می‌شوند و اتصال وسط انتقال فریز می‌شود.",{"question":81,"answer":82},"چطور MTU واقعی مسیر را دقیق پیدا کنم؟","با ping و فلگ -M do اندازه‌ی payload را بالا و پایین ببر. برای MTU=1500 مقدار 1472 بفرست و اگر شکست خورد کم کن تا به بزرگ‌ترین اندازه‌ی سالم برسی؛ آن عدد به‌علاوه‌ی 28 بایت هدر، MTU واقعی مسیر است. اگر ICMP بیرونی مسدود بود، همین تست را به گیت‌وی پیش‌فرض بزن.",{"question":84,"answer":85},"آیا کاهش MTU روی سرور کافی است؟","برای خود سرور بله، چون مبدأ از همان ابتدا بسته‌های کوچک‌تر می‌فرستد. اما اگر سرور نقش روتر دارد یا کلاینت‌های دیگری پشت آن هستند، بهتر است روی گیت‌وی هم TCP MSS clamping را فعال کنی تا همه‌ی اتصال‌ها ایمن بمانند.",[87,13,71],"devops-consulting",true,"چرا بعد از مهاجرت به ابر SSH کار می‌کند ولی scp و HTTPS هنگ می‌کند؟ ریشه در MTU و PMTUD است؛ تشخیص و رفع گام‌به‌گام در لینوکس.",[91,103,118],{"id":26,"title":92,"slug":93,"excerpt":94,"cover":95,"category":97,"author":98,"track":99,"level":100,"reading_minutes":101,"is_featured":27,"published_at":102,"updated_at":102},"قفل state ترافورم گیر کرده؛ آزادسازی امن بعد از کیل شدن apply","terraform-state-lock-stuck-force-unlock","وقتی پایپلاین CI وسط اجرای apply کشته می‌شود، قفل state ترافورم در جدول DynamoDB باقی می‌ماند و اجرای بعدی با خطای Error acquiring the state lock متوقف می‌شود. در این مقاله علت ریشه‌ای، روش آزادسازی امن و راه‌های پیشگیری را بررسی می‌کنیم.",{"url":96,"alt":92},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Fe26789f7-eced-4abb-b6a9-a91adf9b7500.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-08T09:49:26+00:00",{"id":104,"title":105,"slug":106,"excerpt":107,"cover":108,"category":110,"author":113,"track":114,"level":115,"reading_minutes":116,"is_featured":27,"published_at":117,"updated_at":117},12,"خطای fsnotify watcher در Kubernetes؛ سقف inotify نود","kubernetes-fsnotify-watcher-inotify-limit","اگر پادهای Grafana، Prometheus یا هر اپلیکیشنی که از inotify استفاده می‌کند با خطای «failed to create fsnotify watcher: too many open files» کرش می‌کنند، مقصر سقف پیش‌فرض هسته لینوکس روی نود است.",{"url":109,"alt":105},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F4781a89b-ab2c-4250-9677-521b30f6f643.webp",{"name":111,"slug":112},"Kubernetes و کانتینر","kubernetes",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},7,"2026-10-13T09:37:29+00:00",{"id":119,"title":120,"slug":121,"excerpt":122,"cover":123,"category":125,"author":126,"track":127,"level":128,"reading_minutes":101,"is_featured":27,"published_at":129,"updated_at":129},9,"پاد Kubernetes در وضعیت Terminating گیر کرده؛ آزادسازی امن","kubernetes-pod-stuck-terminating-finalizer","پاد در حالت Terminating گیر کرده و با kubectl delete پاک نمی‌شود؟ این مقاله علت واقعی (finalizer باقی‌مانده، نود NotReady، ولوم گیرکرده) و راه‌حل گام‌به‌گام امن را نشان می‌دهد.",{"url":124,"alt":120},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F8e6369a3-ad85-4e7e-8588-183bbd5a31f9.webp",{"name":111,"slug":112},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-10T09:34:08+00:00"]