پروکسی SSM Agent را روی سرویس systemd واقعی آن قرار دهید
از drop-in عامل و دور زدن metadata استفاده کنید، سپس اتصال آن را از درخواست curl خودِ مؤلفه Image Builder تفکیک کنید.
نخست فرستندهٔ ناموفق را مشخص کنید: ارتباط SSM Agent یا دانلودی درون مؤلفهٔ Image Builder. صدور از طریق پوستهٔ SSH عامل در حال اجرا را به‌روزرسانی نمی‌کند.
برای واحد systemd معمول amazon-ssm-agent، drop-in مستندشده را در /etc/systemd/system/amazon-ssm-agent.service.d/override.conf ادغام کنید:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"نقطهٔ پایانی HTTP می‌تواند مقصدهای HTTPS را حمل کند. هنگامی که عامل می‌تواند برای نقاط پایانی عمومی سرویس AWS خود از یک واسط عمومی استفاده کند، فهرست پروکسی HTTP نامزدهایی برای این URLها فراهم می‌کند؛ دور زدن metadata را حفظ کنید. 169.254.169.254 را برای metadata نمونه مستقیماً نگه دارید؛ AWS نیز [fd00:ec2::254] را برای نقطهٔ پایانی metadata در IPv6 مستند کرده است.
پس از تغییر، systemd را دوباره بارگذاری کنید و واحد واقعی عامل را راه‌اندازی مجدد کنید. بسته‌بندی snap اوبونتو از مکان واحد/drop-in دیگری استفاده می‌کند، پس با نصب هماهنگ شوید.
اگر عامل کار می‌کند اما curl مؤلفه شکست می‌خورد، محیط آن فرمان را فراهم کنید. حروف کوچک http_proxy برای curl مهم است؛ یک تراکنش موفق عامل آن ورودی‌های درخواست فرزند را اثبات نمی‌کند.