Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan masalah FAQs
Saat Anda menggunakan AWS SDK for Java 2.x dalam aplikasi Anda, Anda mungkin menemukan kesalahan runtime yang tercantum dalam topik ini. Gunakan saran di sini untuk membantu Anda mengungkap akar penyebab dan menyelesaikan kesalahan.
## Bagaimana cara memperbaiki kesalahan "`java.net.SocketException`: Pengaturan ulang koneksi” atau “server gagal menyelesaikan respons”?
Kesalahan penyetelan ulang koneksi menunjukkan bahwa host Anda Layanan AWS, pihak, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) menutup koneksi sebelum permintaan selesai. Karena ada banyak penyebab, menemukan solusi mengharuskan Anda tahu mengapa koneksi ditutup. Item berikut biasanya menyebabkan koneksi ditutup.
+ **Koneksi tidak aktif.**Ini umum untuk operasi streaming, di mana data tidak ditulis ke atau dari kawat untuk jangka waktu tertentu, sehingga pihak perantara mendeteksi koneksi sebagai mati dan menutupnya. Untuk mencegah hal ini, pastikan aplikasi Anda secara aktif mengunduh atau mengunggah data.
+ **Anda telah menutup klien HTTP atau SDK.** Pastikan untuk tidak menutup sumber daya saat sedang digunakan.
+ **Proxy yang salah dikonfigurasi.** Cobalah untuk melewati proxy apa pun yang telah Anda konfigurasikan untuk melihat apakah itu memperbaiki masalah. Jika ini memperbaiki masalah, proxy menutup koneksi Anda karena alasan tertentu. Teliti proxy spesifik Anda untuk menentukan mengapa itu menutup koneksi.
Jika Anda tidak dapat mengidentifikasi masalah, coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol).
Jika Anda melihat bahwa AWS titik akhir mengirim `TCP RST` (reset), [hubungi layanan yang terpengaruh](https://aws.amazon.com/contact-us/) untuk melihat apakah mereka dapat menentukan mengapa reset terjadi. Bersiaplah untuk memberikan permintaan IDs dan stempel waktu kapan masalah terjadi. Tim AWS dukungan mungkin juga mendapat manfaat dari [log kawat](logging-slf4j.md#sdk-java-logging-verbose) yang menunjukkan dengan tepat byte apa yang dikirim dan diterima aplikasi Anda dan kapan.
## Bagaimana cara memperbaiki “batas waktu koneksi”?
Kesalahan batas waktu koneksi menunjukkan bahwa host Anda, pihak Layanan AWS, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) gagal membuat koneksi baru dengan server dalam batas waktu koneksi yang dikonfigurasi. Item berikut menjelaskan penyebab umum masalah ini.
+ **Batas waktu koneksi yang dikonfigurasi terlalu rendah.** Secara default, batas waktu koneksi adalah 2 detik di file. AWS SDK for Java 2.x Jika Anda mengatur batas waktu koneksi terlalu rendah, Anda mungkin mendapatkan kesalahan ini. Batas waktu koneksi yang disarankan adalah 1 detik jika Anda hanya melakukan panggilan di wilayah dan 3 detik jika Anda membuat permintaan lintas wilayah.
+ **Proxy yang salah dikonfigurasi.** Cobalah untuk melewati proxy apa pun yang Anda konfigurasikan untuk melihat apakah itu memperbaiki masalah. Jika ini memperbaiki masalah, proxy adalah alasan batas waktu koneksi. Teliti proxy spesifik Anda untuk menentukan mengapa hal itu terjadi
Jika Anda tidak dapat mengidentifikasi masalah, coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol) untuk menyelidiki masalah jaringan apa pun.
## Bagaimana cara memperbaiki "`java.net.SocketTimeoutException`: Baca waktunya habis”?
Kesalahan waktu baca menunjukkan bahwa JVM berusaha membaca data dari sistem operasi yang mendasarinya, tetapi data tidak dikembalikan dalam waktu yang dikonfigurasi melalui SDK. Kesalahan ini dapat terjadi jika sistem operasi, pihak Layanan AWS, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) gagal mengirim data dalam waktu yang diharapkan oleh JVM. Karena ada banyak penyebab, menemukan solusi mengharuskan Anda tahu mengapa data tidak dikembalikan.
Coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol).
Jika Anda melihat bahwa AWS titik akhir mengirim `TCP RST` (reset), [hubungi layanan yang terpengaruh](https://aws.amazon.com/contact-us/). Bersiaplah untuk memberikan permintaan IDs dan stempel waktu kapan masalah terjadi. Tim AWS dukungan mungkin juga mendapat manfaat dari [log kawat](logging-slf4j.md#sdk-java-logging-verbose) yang menunjukkan dengan tepat byte apa yang dikirim dan diterima aplikasi Anda dan kapan.
## Bagaimana cara memperbaiki kesalahan “Tidak dapat menjalankan permintaan HTTP: Batas waktu menunggu koneksi dari kumpulan”?
Kesalahan ini menunjukkan bahwa permintaan tidak bisa mendapatkan koneksi dari pool dalam waktu maksimum yang ditentukan. Untuk mengatasi masalah ini, sebaiknya [aktifkan metrik sisi klien SDK untuk memublikasikan metrik ke Amazon](metrics.md). CloudWatch Metrik HTTP dapat membantu mempersempit akar penyebabnya. Item berikut menjelaskan penyebab umum kesalahan ini.
+ **Kebocoran koneksi.** Anda dapat menyelidiki ini dengan memeriksa`LeasedConcurrency`,`AvailableConcurrency`, dan `MaxConcurrency` metrik. Jika `LeasedConcurrency` meningkat hingga mencapai `MaxConcurrency` tetapi tidak pernah berkurang, mungkin ada kebocoran koneksi. Penyebab umum kebocoran adalah karena operasi streaming — seperti metode `getObject` S3 — tidak ditutup. Kami menyarankan agar aplikasi Anda membaca semua data dari aliran input sesegera mungkin dan [menutup aliran input setelahnya](best-practices.md#bestpractice2). Bagan berikut menunjukkan seperti apa metrik SDK untuk kebocoran koneksi.
![\[Tangkapan layar CloudWatch metrik yang menunjukkan kemungkinan kebocoran koneksi.\]](http://docs.aws.amazon.com/id_id/sdk-for-java/latest/developer-guide/images/JavaDevGuide-connection-leak-metrics-chart.png)
+ **Kelaparan kolam koneksi.**Hal ini dapat terjadi jika tingkat permintaan Anda terlalu tinggi dan ukuran kumpulan koneksi yang telah dikonfigurasi tidak dapat memenuhi permintaan permintaan. Ukuran kumpulan koneksi default adalah 50, dan ketika koneksi di kolam mencapai maksimum, klien HTTP mengantri permintaan masuk hingga koneksi tersedia. Bagan berikut menunjukkan seperti apa metrik SDK untuk kelaparan kumpulan koneksi.
![\[Tangkapan layar CloudWatch metrik yang menunjukkan bagaimana kelaparan kumpulan koneksi mungkin terlihat.\]](http://docs.aws.amazon.com/id_id/sdk-for-java/latest/developer-guide/images/JavaDevGuide-connection-pool-starvation-chart.png)
Untuk mengurangi masalah ini, pertimbangkan untuk mengambil salah satu tindakan berikut.
+ Tingkatkan ukuran kolam koneksi,
+ Tingkatkan batas waktu akuisisi.
+ Memperlambat tingkat permintaan.
Dengan meningkatkan jumlah maksimum koneksi, throughput klien dapat meningkat (kecuali antarmuka jaringan sudah sepenuhnya digunakan). Namun, Anda akhirnya dapat menekan batasan sistem operasi pada jumlah deskriptor file yang digunakan oleh proses. Jika Anda sudah sepenuhnya menggunakan antarmuka jaringan Anda atau tidak dapat meningkatkan jumlah koneksi Anda lebih lanjut, coba tingkatkan batas waktu perolehan. Dengan peningkatan ini, Anda mendapatkan waktu ekstra untuk permintaan untuk mendapatkan koneksi sebelum waktu habis. Jika koneksi tidak bebas, permintaan berikutnya akan tetap batas waktu.
Jika Anda tidak dapat memperbaiki masalah dengan menggunakan dua mekanisme pertama, perlambat tingkat permintaan dengan mencoba opsi berikut.
+ Menghaluskan permintaan Anda sehingga semburan lalu lintas yang besar tidak membebani klien.
+ Lebih efisien dengan panggilan ke Layanan AWS.
+ Tingkatkan jumlah host yang mengirim permintaan.
+ **I/O Thread terlalu sibuk.** Ini hanya berlaku jika Anda menggunakan klien SDK asinkron dengan. [https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/http/nio/netty/NettyNioAsyncHttpClient.html](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/http/nio/netty/NettyNioAsyncHttpClient.html) Jika `AvailableConcurrency` metriknya tidak rendah—menunjukkan bahwa koneksi tersedia di kolam—tetapi `ConcurrencyAcquireDuration` tinggi, itu mungkin karena I/O utas tidak dapat menangani permintaan. Pastikan Anda tidak lulus `Runnable:run` sebagai [pelaksana penyelesaian masa depan](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/client/config/SdkAdvancedAsyncClientOption.html#FUTURE_COMPLETION_EXECUTOR) dan melakukan tugas yang memakan waktu dalam rantai penyelesaian masa depan respons karena ini dapat memblokir I/O utas. Jika bukan itu masalahnya, pertimbangkan untuk menambah jumlah I/O utas dengan menggunakan `[eventLoopGroupBuilder](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/http/nio/netty/NettyNioAsyncHttpClient.Builder.html#eventLoopGroupBuilder(software.amazon.awssdk.http.nio.netty.SdkEventLoopGroup.Builder))` metode ini. Sebagai referensi, jumlah default thread I/O untuk sebuah `NettyNioAsyncHttpClient` instance adalah dua kali jumlah core CPU host.
+ **Latensi jabat tangan TLS tinggi.** Jika `AvailableConcurrency` metrik Anda mendekati 0 dan `LeasedConcurrency` lebih rendah dari`MaxConcurrency`, mungkin karena latensi jabat tangan TLS tinggi. Bagan berikut menunjukkan seperti apa metrik SDK untuk latensi jabat tangan TLS yang tinggi.
![\[Tangkapan layar CloudWatch metrik yang mungkin menunjukkan latensi jabat tangan TLS yang tinggi.\]](http://docs.aws.amazon.com/id_id/sdk-for-java/latest/developer-guide/images/JavaDevGuide-high-tls-latency-chart.png)
Untuk klien HTTP yang ditawarkan oleh Java SDK yang tidak didasarkan pada CRT, coba aktifkan [log TLS untuk memecahkan masalah TLS](security-java-tls.md). [Untuk klien HTTP AWS berbasis CRT, coba aktifkan AWS log CRT.](logging-slf4j.md#sdk-java-logging-verbose) Jika Anda melihat bahwa AWS titik akhir tampaknya membutuhkan waktu lama untuk melakukan jabat tangan TLS, Anda harus [menghubungi layanan yang terpengaruh](https://aws.amazon.com/contact-us/).
## Bagaimana cara memperbaiki`NoClassDefFoundError`, `NoSuchMethodError` atau`NoSuchFieldError`?
A `NoClassDefFoundError` menunjukkan bahwa kelas tidak dapat dimuat saat runtime. Dua penyebab paling umum untuk kesalahan ini adalah:
+ kelas tidak ada di classpath karena JAR hilang atau versi JAR yang salah ada di classpath.
+ kelas gagal memuat karena penginisialisasi statisnya memberikan pengecualian.
Demikian pula, `NoSuchMethodError` s dan `NoSuchFieldError` s biasanya dihasilkan dari versi JAR yang tidak cocok. Kami menyarankan Anda melakukan langkah-langkah berikut.
1. **Periksa dependensi Anda** untuk memastikan bahwa Anda menggunakan *versi yang sama dari semua stoples SDK*. Alasan paling umum bahwa kelas, metode, atau bidang tidak dapat ditemukan adalah ketika Anda meningkatkan ke versi klien baru tetapi Anda terus menggunakan versi ketergantungan SDK 'bersama' lama. Versi klien baru mungkin mencoba menggunakan kelas yang hanya ada di dependensi SDK 'bersama' yang lebih baru. Coba jalankan `mvn dependency:tree` atau `gradle dependencies` (untuk Gradle) untuk memverifikasi bahwa semua versi pustaka SDK cocok. Untuk menghindari masalah ini sepenuhnya di masa mendatang, sebaiknya gunakan [BOM (Bill of Materials)](setup-project-maven.md#sdk-as-dependency) untuk mengelola versi modul SDK.
Contoh berikut menunjukkan contoh versi SDK campuran.
```
[INFO] +- software.amazon.awssdk:dynamodb:jar:2.20.00:compile
[INFO] | +- software.amazon.awssdk:aws-core:jar:2.13.19:compile
[INFO] +- software.amazon.awssdk:netty-nio-client:jar:2.20.00:compile
```
Versi `dynamodb` adalah 2.20.00 dan versi 2.13.19`aws-core`. Versi `aws-core` artefak juga harus 2.20.00.
1. **Periksa pernyataan di awal log Anda** untuk melihat apakah kelas gagal dimuat karena kegagalan inisialisasi statis. Pertama kali kelas gagal memuat, mungkin ada pengecualian yang berbeda dan lebih berguna yang menentukan *mengapa* kelas tidak dapat dimuat. Pengecualian yang berpotensi berguna ini hanya terjadi sekali, jadi pernyataan log selanjutnya hanya akan melaporkan bahwa kelas tidak ditemukan.
1. **Periksa proses penyebaran Anda** untuk memastikan bahwa itu benar-benar menyebarkan file JAR yang diperlukan bersama dengan aplikasi Anda. Ada kemungkinan bahwa Anda sedang membangun dengan versi yang benar, tetapi proses yang membuat classpath untuk aplikasi Anda tidak termasuk dependensi yang diperlukan.
## Bagaimana cara memperbaiki kesalahan "`SignatureDoesNotMatch`" atau “Tanda tangan permintaan yang kami hitung tidak cocok dengan tanda tangan yang Anda berikan”?
`SignatureDoesNotMatch`Kesalahan menunjukkan bahwa tanda tangan yang dihasilkan oleh AWS SDK untuk Java dan tanda tangan yang dihasilkan oleh Layanan AWS tidak cocok. Item berikut menjelaskan penyebab potensial.
+ Pihak proxy atau perantara memodifikasi permintaan. Misalnya, proxy atau penyeimbang beban dapat mengubah header, path, atau string kueri yang ditandatangani oleh SDK.
+ Layanan dan SDK berbeda dalam cara mereka menyandikan permintaan ketika masing-masing menghasilkan string untuk ditandatangani.
Untuk men-debug masalah ini, sebaiknya [aktifkan logging debug untuk SDK](logging-slf4j.md#sdk-debug-level-logging). Cobalah untuk mereproduksi kesalahan dan temukan permintaan kanonik yang dihasilkan SDK. Di log, permintaan kanonik diberi label `AWS4 Canonical Request: ...` dan string yang akan ditandatangani diberi label. `AWS4 String to sign: ...`
Jika Anda tidak dapat mengaktifkan debugging—misalnya, karena hanya dapat direproduksi dalam produksi—tambahkan logika ke aplikasi Anda yang mencatat informasi tentang permintaan saat terjadi kesalahan. Anda kemudian dapat menggunakan informasi tersebut untuk mencoba mereplikasi kesalahan di luar produksi dalam pengujian integrasi dengan logging debug diaktifkan.
Setelah Anda mengumpulkan permintaan kanonik dan string untuk ditandatangani, bandingkan dengan [spesifikasi AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) untuk menentukan apakah ada masalah dalam cara SDK menghasilkan string untuk ditandatangani. Jika ada yang salah, Anda dapat membuat [laporan GitHub bug](https://github.com/aws/aws-sdk-java-v2/issues/new/choose) ke file AWS SDK untuk Java.
Jika tidak ada yang salah, Anda dapat membandingkan string SDK untuk ditandatangani dengan string untuk menandatangani bahwa beberapa Layanan AWS kembali sebagai bagian dari respons kegagalan (Amazon S3, misalnya). Jika ini tidak tersedia, Anda harus [menghubungi layanan yang terpengaruh](https://aws.amazon.com/contact-us/) untuk melihat permintaan dan string kanonik apa yang akan ditandatangani yang dihasilkan untuk perbandingan. Perbandingan ini dapat membantu mengidentifikasi pihak perantara yang mungkin telah memodifikasi permintaan atau menyandikan perbedaan antara layanan dan klien.
Untuk informasi latar belakang selengkapnya tentang permintaan [penandatanganan, lihat Menandatangani permintaan AWS API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) di Panduan AWS Identity and Access Management Pengguna.
**Example dari permintaan kanonik**
```
PUT
/Example-Bucket/Example-Object
partNumber=19&uploadId=string
amz-sdk-invocation-id:f8c2799d-367c-f024-e8fa-6ad6d0a1afb9
amz-sdk-request:attempt=1; max=4
content-encoding:aws-chunked
content-length:51
content-type:application/octet-stream
host:xxxxx
x-amz-content-sha256:STREAMING-UNSIGNED-PAYLOAD-TRAILER
x-amz-date:20240308T034733Z
x-amz-decoded-content-length:10
x-amz-sdk-checksum-algorithm:CRC32
x-amz-trailer:x-amz-checksum-crc32
```
**Example dari string untuk ditandatangani**
```
AWS4-HMAC-SHA256
20240308T034435Z
20240308/us-east-1/s3/aws4_request
5f20a7604b1ef65dd89c333fd66736fdef9578d11a4f5d22d289597c387dc713
```
## Bagaimana cara memperbaiki kesalahan "`java.lang.IllegalStateException`: Connection pool shut down”?
Kesalahan ini menunjukkan kumpulan koneksi HTTP Apache yang mendasarinya ditutup. Item berikut menjelaskan penyebab potensial.
+ **Klien SDK ditutup sebelum waktunya.**SDK hanya menutup kumpulan koneksi saat klien terkait ditutup. Pastikan untuk tidak menutup sumber daya saat sedang digunakan.
+ **A `java.lang.Error` dilemparkan.** Kesalahan seperti `OutOfMemoryError` menyebabkan kolam koneksi HTTP Apache [dimatikan.](https://github.com/apache/httpcomponents-client/blob/6a741b4f8f23e6c5c7cc42c36c2acabfac19c3d6/httpclient/src/main/java/org/apache/http/impl/execchain/MainClientExec.java#L368) Periksa log Anda untuk jejak tumpukan kesalahan. Juga tinjau kode Anda untuk tempat-tempat di mana ia menangkap `Throwable` s atau `Error` s tetapi menelan output yang mencegah kesalahan muncul ke permukaan. Jika kode Anda tidak melaporkan kesalahan, tulis ulang kode sehingga informasi dicatat. Informasi yang dicatat membantu menentukan akar penyebab kesalahan.
+ **Anda mencoba menggunakan penyedia kredensyal yang dikembalikan `DefaultCredentialsProvider#create()` setelah ditutup**. [https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html#create()](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html#create())mengembalikan instance tunggal, jadi jika ditutup dan kode Anda memanggil `resolveCredentials` metode, pengecualian dilemparkan setelah kredensi cache (atau token) kedaluwarsa.
Periksa kode Anda untuk tempat-tempat di mana `DefaultCredentialsProvider` ditutup, seperti yang ditunjukkan pada contoh berikut.
+ Instance singleton ditutup dengan memanggil `DefaultCredentialsProvider#close().`
```
DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // Singleton instance returned.
AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
// Make calls to Layanan AWS.
defaultCredentialsProvider.close(); // Explicit close.
// Make calls to Layanan AWS.
// After the credentials expire, either of the following calls eventually results in a "Connection pool shut down" exception.
credentials = defaultCredentialsProvider.resolveCredentials();
// Or
credentials = DefaultCredentialsProvider.create().resolveCredentials();
```
+ Memanggil `DefaultCredentialsProvider#create()` dalam satu try-with-resources blok.
```
try (DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create()) {
AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
// Make calls to Layanan AWS.
} // After the try-with-resources block exits, the singleton DefaultCredentialsProvider is closed.
// Make calls to Layanan AWS.
DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // The closed singleton instance is returned.
// If the credentials (or token) has expired, the following call results in the error.
AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
```
Buat instance baru, non-singleton dengan memanggil `DefaultCredentialsProvider.builder().build()` jika kode Anda telah menutup instance tunggal dan Anda perlu menyelesaikan kredensialnya dengan menggunakan file. `DefaultCredentialsProvider`
## Bagaimana cara memperbaiki “Tidak dapat memuat kredensyal dari salah satu penyedia dalam rantai “? AwsCredentialsProviderChain
Kesalahan ini menunjukkan bahwa tidak AWS SDK for Java 2.x dapat menemukan AWS kredensyal yang valid melalui salah satu penyedia kredensi dalam rantai penyedia kredensyal default. SDK secara otomatis mencari kredensyal dalam urutan tertentu, dan kesalahan ini terjadi ketika semua penyedia dalam rantai gagal memberikan kredensyal yang valid.
Pesan kesalahan lengkap biasanya terlihat seperti ini (akhiran baris dan indentasi ditambahkan untuk meningkatkan keterbacaan):
```
Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(
credentialsProviders=[
SystemPropertyCredentialsProvider(),
EnvironmentVariableCredentialsProvider(),
WebIdentityTokenCredentialsProvider(),
ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])),
ContainerCredentialsProvider(),
InstanceProfileCredentialsProvider()
]) : [
SystemPropertyCredentialsProvider(): Unable to load credentials from system settings.
Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID)
or system property (aws.accessKeyId).,
EnvironmentVariableCredentialsProvider(): Unable to load credentials from system settings.
Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID)
or system property (aws.accessKeyId).,
WebIdentityTokenCredentialsProvider(): To use web identity tokens, the 'sts' service module
must be on the class path.,
ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])):
Profile file contained no credentials for profile 'default': ProfileFile(sections=[]),
ContainerCredentialsProvider(): Cannot fetch credentials from container - neither
AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment
variables are set.,
InstanceProfileCredentialsProvider(): Failed to load credentials from IMDS.]
```
### Penyebab dan solusi umum
#### Tinjau konfigurasi kredensyal Anda
Saat Anda menggunakan penyedia kredensyal default (dengan menelepon `ServiceClient.create()` tanpa mengonfigurasi kredensyal secara eksplisit), SDK akan mencari kredensyal dalam urutan tertentu. Tinjau [cara kerja rantai penyedia kredensyal default](credentials-chain.md) untuk memahami sumber kredensyal mana yang diperiksa SDK dan dalam urutan apa.
Pastikan bahwa metode konfigurasi kredensyal yang ingin Anda gunakan diatur dengan benar di lingkungan Anda:
##### Untuk instans Amazon EC2
+ **Periksa peran IAM:** Verifikasi bahwa peran IAM dilampirkan ke instance Anda.
+ Kegagalan **IMDS intermiten: Jika Anda mengalami kegagalan** intermiten (biasanya berlangsung beberapa ratus milidetik), ini biasanya menunjukkan masalah jaringan sementara yang mencapai Layanan Metadata Instans (IMDS).
Solusi:
+ Aktifkan [pencatatan debug](logging-slf4j.md#sdk-debug-level-logging) untuk menganalisis waktu dan frekuensi kegagalan
+ Pertimbangkan untuk menerapkan logika coba lagi dalam aplikasi Anda untuk kegagalan terkait kredensyal
+ Periksa masalah konektivitas jaringan antara instans Anda dan titik akhir IMDS
##### Untuk lingkungan kontainer
Konfirmasikan bahwa peran tugas (Amazon ECS) atau akun layanan (Amazon EKS) dikonfigurasi dan variabel lingkungan yang diperlukan disetel.
##### Untuk pengembangan lokal
Periksa apakah variabel lingkungan, file kredensyal, atau konfigurasi Pusat Identitas IAM sudah ada.
##### Untuk federasi identitas web
+ **Verifikasi konfigurasi:** Verifikasi bahwa file token identitas web ada dan variabel lingkungan yang diperlukan dikonfigurasi.
+ **Ketergantungan modul STS yang hilang:** Jika Anda melihat kesalahan`To use web identity tokens, the 'sts' service module must be on the class path`, Anda perlu menambahkan modul STS sebagai ketergantungan. Ini biasa terjadi saat menggunakan Amazon EKS Pod Identity atau otentikasi token identitas web lainnya.
Solusi: Tambahkan modul STS ke dependensi proyek Anda:
+
```
software.amazon.awssdk
sts
```
Untuk beberapa layanan, Anda mungkin juga memerlukan `aws-query-protocol` ketergantungan:
```
software.amazon.awssdk
aws-query-protocol
```
#### Masalah konektivitas jaringan atau proxy
Jika Anda melihat `Connection refused` kesalahan dalam rantai penyedia kredensyal, ini biasanya menunjukkan masalah konektivitas jaringan saat SDK mencoba mencapai AWS titik akhir.
**Solusi:**
+ Verifikasi konfigurasi proxy jika Anda menggunakan server proxy
+ Periksa apakah jaringan Anda mengizinkan koneksi HTTPS keluar ke titik akhir AWS
+ Aktifkan [pencatatan debug](logging-slf4j.md#sdk-debug-level-logging) untuk melihat upaya koneksi terperinci
+ Uji konektivitas menggunakan alat seperti `curl` memverifikasi akses jaringan ke titik AWS akhir