Legi la konektajn fiaskokodojn de SOCKS5
Identigu ĉu fiaskis SOCKS-intertraktado, aŭtentikigo aŭ la celaliro antaŭ ol trakti ĉiun SOCKS-eraron kiel mortan prokurilon.
SOCKS5-servilo povas akcepti vian TCP-konekton kaj tamen rifuzi la peton atingi celon. Legu la respondon en la ĝusta fazo antaŭ ol decidi kiu finpunkto fiaskis.
Unue okazas metodolekto. Uzantnomo/pasvorta aŭtentikigo, se elektita, havas propran rezulton. Nur poste la servilo redonas la respondon por CONNECT aŭ alia SOCKS-komando. Bajtovaloro el unu fazo ne interpreteblas per la tabelo de alia fazo.
Petorespondoj distingas diversajn fiaskojn
| Respondvaloro | Signifo en la SOCKS5-petorespondo |
|---|---|
| 0x01 | Ĝenerala servila fiasko. |
| 0x02 | Konekto ne permesita de la regularo. |
| 0x03 | Reto neatingebla. |
| 0x04 | Gastiganto neatingebla. |
| 0x05 | Konekto rifuzita. |
| 0x06 | TTL eksvalidiĝis. |
| 0x07 | Komando ne subtenata. |
| 0x08 | Adrestipo ne subtenata. |
Ekzemple, petonivela rifuzo estas raportata post atingo de la SOCKS-servo. Ĝi malsamas al tio, ke via operaciumo rifuzas la komencan TCP-konekton al tiu servo.
Adrestipa eraro povas koncerni prezenton kiel IPv4, IPv6 aŭ gastigantnomo. Ĝi ne aŭtomate signifas ke la tuta finpunkto ne subtenas SOCKS5. Same, nesubtenata UDP-komando diras nenion definitivan pri aparta TCP CONNECT-peto.
Kolektu la kuntekston kiu utiligas la kodon
Kiam vi skribas erarraporton, konservu kun la rezulto la prokuriladreson, komandon, celan gastiganton kaj pordon, adresfamilion kaj DNS-reĝimon. Servilaj politikprotokoloj utilas se vi administras la finpunkton. Regulara rifuzo postulas kontrolon de la aplikebla permeso, ne pligrandigon de konekta tempolimo.
La respondo estas raporto de la servilo, ne plena sendependa diagnozo de la cela reto. Ankaŭ la klienta vortumo varias. Registru la fazon kaj la suban respondon kiam haveblaj anstataŭ fidi nur mallongan tradukitan erarmesaĝon.