Ang bypass ng proxy ng s3fs ay dapat tumugma sa aktwal na hostname ng bucket
Itugma ang panuntunan sa bypass ng s3fs sa aktwal na endpoint ng S3, kabilang ang mga hostname na bucket-style at mga redirect.
s3.amazonaws.com ay hindi tumutugma sa photos.s3.us-east-1.amazonaws.com. Ang rehiyonal na hostname ay hindi nagtatapos sa naka-configure na domain na iyon. Ang pagbubukod ng domain ay maaaring magsama ng mga subdomain, ngunit hindi nito matukoy ang bawat endpoint ng isang serbisyo ng imbakan.
Hanapin ang host na aktwal na kinokontak ng s3fs, kabilang ang mga susunod na redirect. Inilalagay ng virtual-hosted addressing ang bucket sa hostname; inilalagay ng path-style addressing ito sa path. Kaya maaaring baguhin ng custom na endpoint o pagwawasto ng rehiyon ang pangalang kailangang tugmaan ng panuntunan sa bypass.
Gamitin ang use_path_request_style kapag kailangan ng serbisyo ang anyo ng addressing na iyon. Ang pagbabago nito para lamang gumana ang isang hindi maipaliwanag na pagbubukod ng proxy ay naghahalo ng dalawang desisyon at maaaring makaapekto sa mga pangalan ng sertipiko at pagiging tugma ng serbisyo.
Gumagamit ang s3fs ng libcurl para sa mga paglilipat ng HTTP, at maaari ring ibukod ng no_proxy ang mga destinasyong HTTPS. Pumili ng pagbubukod ng hostname o domain na sapat ang lawak para sa mga nilalayong direktang kahilingan. Maaaring kabilang sa mas malawak na domain ang iba pang bucket at serbisyo; ang * ay ganap na nagpapahina sa paggamit ng proxy para sa naaangkop na kahilingan.
Kung gumagana ang parehong endpoint mula sa isang interactive na mount ngunit hindi mula sa mount na pinamamahalaan ng serbisyo, ihambing ang kanilang minanang kapaligiran at mga pinagmulan ng configuration. Ang pag-export ng variable pagkatapos magsimula ang serbisyo ay hindi maaaring i-update ang umiiral na prosesong iyon. Itatag ang pangalan ng endpoint at mga input ng proseso ng mount bago baguhin ang mga kredensyal ng bucket.