503 Servizio non disponibile

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Video

Per ulteriori informazioni sugli errori 503, guarda i seguenti video:

Video Descrizione
Risoluzione dei problemi e risoluzione dell'errore 503 Service Unavailable dovuto a un problema DNS Scopri di più su:
  • Errore 503 Service Unavailable causato da problemi di risoluzione DNS e di rete in Apigee Edge
  • Risoluzione dei problemi e risoluzione di un errore 503 Servizio non disponibile in tempo reale causato da un problema di risoluzione DNS
Risolvere l'errore 503 Service Unavailable dovuto a un problema di rete Risoluzione dei problemi e risoluzione di un errore 503 Service Unavailable in tempo reale causato da un problema di rete in Apigee Edge

Sintomo

L'applicazione client riceve uno stato della risposta HTTP 503 con il messaggio Service Unavailable dopo una chiamata al proxy API.

Messaggi di errore

Potresti visualizzare il seguente messaggio di errore:

HTTP/1.1 503 Service Unavailable

Puoi anche visualizzare il seguente messaggio di errore nella risposta HTTP:

Servizio non disponibile

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Possibili cause

La risposta HTTP 503 Service Unavailable con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable si verifica se il processore di messaggi di Apigee Edge rileva errori dovuti a timeout di connessione, nome host errato o errori di handshake SSL durante la comunicazione con il server di backend.

Le possibili cause della risposta 503 Service Unavailable sono:

Causa Descrizione Chi può eseguire i passaggi per la risoluzione dei problemi
Errori di connessione dovuti a una risoluzione DNS errata La risoluzione DNS del server di destinazione ha generato indirizzi IP errati che hanno causato errori di connessione. Utenti di Edge Private Cloud
Errori di connessione Problemi di rete o di connettività impediscono al client di connettersi al server. Utenti di Edge Private Cloud
Nome host del server di destinazione errato L'host del server di destinazione specificato non è corretto o contiene caratteri indesiderati (ad esempio uno spazio). Utenti di Edge Public e Private Cloud
Errori di handshake SSL L'handshake TLS/SSL non è riuscito tra il client e il server. (La risoluzione dei problemi per questa classe di problemi è trattata in un argomento separato). Utenti di Edge Public e Private Cloud

Passaggi di diagnostica comuni

Determinare l'ID messaggio della richiesta non riuscita

Strumento Traccia

Per determinare l'ID messaggio della richiesta non riuscita utilizzando lo strumento Trace:

  1. Se il problema è ancora attivo, abilita la sessione di tracciamento per l'API interessata.
  2. Esegui la chiamata API e riproduci il problema: errore 503 Servizio non disponibile con codice di errore messaging.adaptors.http.flow.ServiceUnavailable.
  3. Seleziona una delle richieste non riuscite.
  4. Vai alla fase AX e determina l'ID messaggio (X-Apigee.Message-ID) della richiesta scorrendo verso il basso nella sezione Dettagli fase, come mostrato nella figura seguente.

    ID messaggio nella sezione Dettagli fase

Log degli accessi NGINX

Per determinare l'ID messaggio della richiesta non riuscita utilizzando i log di accesso NGINX:

Puoi anche fare riferimento ai log di accesso NGINX per determinare l'ID messaggio per gli errori 503. Ciò è particolarmente utile se il problema si è verificato in passato o se è intermittente e non riesci ad acquisire la traccia nell'interfaccia utente. Per determinare queste informazioni dai log di accesso NGINX:

  1. Controlla i log di accesso NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Cerca eventuali errori 503 per il proxy API specifico durante un periodo di tempo specifico (se il problema si è verificato in passato) o se alcune richieste continuano a non riuscire con l'errore 503.
  3. Se si verificano errori 503 con X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable, annotare l'ID messaggio per una o più richieste di questo tipo, come mostrato nell'esempio seguente:

    Voce di esempio che mostra l'errore 503

    Voce di esempio che mostra il codice di stato, l'ID messaggio, l'origine dell'errore e il codice di errore

Errori di connessione dovuti a una risoluzione DNS errata

Diagnosi

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio della richiesta specifica nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti riscontrare i seguenti errori:

    Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout di connessione preimpostato (valore predefinito: 3 secondi). 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22

2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
  3. Prendi nota dell'indirizzo IP risolto nell'errore onConnectTimeout e verifica se l'indirizzo IP è valido per il tuo server di backend. Se l'indirizzo IP è valido, vai a Errori di connessione.
  4. Se l'indirizzo IP non è valido, è molto probabile che il problema sia dovuto a problemi di risoluzione DNS.
  5. Ripeti i passaggi 3 e 4 per altre richieste API non riuscite e verifica se visualizzi gli stessi indirizzi IP non validi o altri.
  6. Cerca nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) i messaggi con la parola chiave Aggiornamento DNS. Controlla di tanto in tanto se vengono aggiunti indirizzi IP errati o non validi alla cache DNS sul processore di messaggi. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
  7. Questo problema può verificarsi se ci sono problemi con i server DNS autorevoli o con i server dei nomi configurati in /etc/resolv.conf.

    In genere, possono essere configurati uno o più server DNS autorevoli per eseguire la risoluzione DNS. Se non sono presenti server DNS autorevoli, verrà ripristinata la configurazione impostata in /etc/resolv.conf e verrà eseguita la risoluzione DNS in modo appropriato. Ad esempio, se /etc/resolv.conf è configurato per utilizzare server dei nomi specifici, questi verranno utilizzati per eseguire la risoluzione DNS.
  8. Se si verificano problemi con i server DNS autorevoli o i server dei nomi specificati in /etc/resolv.conf, i nomi host del server di backend verranno risolti in indirizzi IP errati/non validi. Gli indirizzi IP non validi/errati verranno quindi archiviati nella cache DNS del processore di messaggi.
    1. Se il problema con i server DNS autoritativi o i server dei nomi specificati in /etc/resolv.conf persiste, gli indirizzi IP non validi/errati continueranno a rimanere nella cache DNS del processore di messaggi. Finché gli indirizzi IP non validi sono memorizzati nella cache DNS del processore di messaggi, le richieste per tutte le API che utilizzano il server di backend specifico non andranno a buon fine e verrà visualizzato l'errore 503.
    2. Se il problema con i server DNS autoritativi o i server dei nomi specificati in /etc/resolv.conf è intermittente, gli indirizzi IP buoni e cattivi verranno archiviati in modo intermittente nella cache DNS. In questo caso, vedrai errori 503 a intermittenza per tutte le API che utilizzano il server di backend specifico.
  9. Se il problema con i server DNS è persistente, vedrai errori continui. Se il problema con i server DNS è intermittente, vedrai errori intermittenti. ovvero ogni volta che il nome host del server di backend viene risolto in indirizzi IP errati, vengono visualizzati errori 503. Quando i nomi host del server di backend vengono risolti in indirizzi IP validi, vedrai risposte riuscite.

Risoluzione

Collabora con l'amministratore del sistema operativo e risolvi i problemi relativi ai server DNS.

  1. Se si verifica un problema con i server DNS autorevoli o i server dei nomi specificati in /etc/resolv.conf, risolvi il problema con il server appropriato.
  2. Se si verifica un problema con la configurazione in /etc/resolv.conf sui sistemi con Message Processor, correggi il problema di configurazione.

Errori di connessione

Si verifica un errore di connessione quando un processore di messaggi di Apigee Edge tenta di connettersi a un server di backend e si verifica uno di questi problemi:

  • Il processore di messaggi non è in grado di connettersi entro il periodo di timeout della connessione preimpostato. (valore predefinito: 3 secondi)
  • Il server di backend rifiuta la connessione.

Diagnosi

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio di richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti riscontrare i seguenti errori:
    1. Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout di connessione preimpostato. 
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
    2. Un errore java.net.ConnectException: Connection refused indica che la connessione è stata rifiutata dal server di backend. 
      14:40:16.531 +0530
2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
  3. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascuno dei Message Processor utilizzando il comando telnet:
    1. Se il server di backend viene risolto in un singolo indirizzo IP, utilizza il seguente comando: 
      telnet BackendServer-IPaddress 443
    2. Se il server di backend viene risolto in più indirizzi IP, utilizza il nome host del server di backend nel comando telnet come mostrato di seguito: 
      telnet BackendServer-HostName 443
  4. Se riesci a connetterti al server di backend, potresti visualizzare un messaggio come Connected to backend-server. Se non riesci a connetterti al server di backend, il problema potrebbe essere che gli indirizzi IP dei processori di messaggi non sono inclusi nella lista consentita del server di backend specifico.

Risoluzione

Concedi l'accesso agli indirizzi IP del processore di messaggi sul server di backend specifico per consentire al traffico dei processori di messaggi Edge di accedere al tuo server di backend. Ad esempio, su Linux puoi utilizzare iptables per consentire il traffico dagli indirizzi IP del processore di messaggi sul server di backend.

Se il problema persiste, collabora con l'amministratore di rete per determinare e risolvere il problema. Se hai bisogno di ulteriore assistenza da parte di Apigee, contatta l'assistenza Apigee.

Nome host del server di destinazione errato

Diagnosi

Se il nome host specificato nel server di destinazione non è corretto, puoi ricevere una risposta 503 Service Unavailable con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable.

Strumento Traccia

Per eseguire la diagnostica utilizzando lo strumento Traccia:

  1. Se il problema è ancora attivo, abilita la sessione di tracciamento per l'API interessata.
  2. Esegui la chiamata API e riproduci il problema: errore 503 Servizio non disponibile con codice di errore messaging.adaptors.http.flow.ServiceUnavailable.
  3. Seleziona una delle richieste non riuscite.
  4. Esamina le varie fasi della traccia e individua il punto in cui si è verificato l'errore.
  5. Seleziona FlowInfo che presenta l'errore. Puoi trovare maggiori informazioni nel campo error.cause, che può indicare la causa dell'errore, come mostrato nell'esempio seguente:

    Richiesta di esempio che mostra error.cause nella traccia

    Richiesta di esempio che mostra error.cause nella traccia
  6. Se noti che error.cause mostra Host non raggiungibile, la causa probabile dell'errore è una delle seguenti:
    • Il nome host specificato nella configurazione del server di destinazione/dell'endpoint di destinazione non è corretto o contiene spazi o caratteri speciali indesiderati.

      Ad esempio, nel nome host è presente uno spazio indesiderato, come mostrato di seguito:
      "demo-target.apigee.net "
    • Il nome host sovrascritto dalla variabile target.url nel proxy API utilizzando il criterio AssignMessage o JavaScript non è corretto o contiene uno spazio o altri caratteri speciali indesiderati.
  7. Controlla la configurazione dell'endpoint di destinazione e/o la definizione del server di destinazione per verificare se il nome host del server di destinazione è errato o contiene spazi o caratteri speciali indesiderati.
  8. Se l'host del server di destinazione viene creato dinamicamente, controlla il criterio appropriato (ad esempio il criterio AssignMessage/JavaScript) utilizzato per crearlo. Controlla se il nome host del server di destinazione è errato o contiene spazi o caratteri speciali indesiderati.
  9. Una volta determinato il nome host del server di destinazione, esegui il comando nslookup/dig sul nome host per verificare se può essere risolto.

    Ad esempio, l'esecuzione del comando nslookup sul nome host con uno spazio indesiderato restituisce il seguente output:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Se anche il comando del sistema operativo nslookup non riesce a risolvere il nome host, la causa di questo problema è il nome host errato utilizzato per il server di destinazione.

    Vai a Risoluzione.

Log del processore di messaggi

Per eseguire la diagnosi utilizzando i log del processore di messaggi:

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio nel log del processore di messaggi. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Se visualizzi i seguenti messaggi di avviso/errore, significa che il processore di messaggi non è riuscito a risolvere il nome host. Poiché il messaggio verrà posticipato, potresti non visualizzare questo messaggio di avviso per tutti gli ID messaggio/richieste. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. Seguirà un messaggio di avviso in cui il processore di messaggi rimuove l'indirizzo dalla cache DNS perché non è stato possibile raggiungere l'host del server di destinazione. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. Potresti quindi visualizzare un messaggio in cui il processore di messaggi non riesce a eseguire l'operazione con l'eccezione "Host non raggiungibile". A volte il nome host viene visualizzato nel messaggio di errore: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. A volte potrebbe essere visualizzato come null perché il nome host non può essere risolto o raggiunto, come mostrato di seguito: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. L'errore Host not reachable si verifica in genere in uno dei seguenti casi:
    • Il nome host specificato nella configurazione del server di destinazione/dell'endpoint di destinazione non è corretto o contiene spazi o caratteri speciali indesiderati.

      Ad esempio, nel seguente messaggio di errore è presente uno spazio indesiderato nel nome host "demo-target.apigee.net ": 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • Il nome host sovrascritto dalla variabile target.url nel proxy API utilizzando il criterio AssignMessage o JavaScript non è corretto o contiene uno spazio o altri caratteri speciali indesiderati.
  8. Determina il nome host del server di destinazione con cui il processore di messaggi sta tentando di comunicare utilizzando uno dei seguenti metodi:
    1. Esamina attentamente il messaggio di errore contenente Host not reachable .
    2. Se il messaggio di errore mostra il nome host, copialo includendo eventuali spazi o caratteri speciali.
    3. Se il messaggio di errore mostra null per il nome host, come nel seguente messaggio di errore, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. Determina il nome host controllando la definizione del server di destinazione utilizzata nel proxy API non riuscito.
      2. Se l'host del server di destinazione viene creato dinamicamente, controlla la policy appropriata (ad esempio, la policy AssignMessage/JavaScript) utilizzata per crearlo.
  9. Una volta determinato il nome host del server di destinazione, esegui il comando nslookup/dig sul nome host e verifica se può essere risolto.

    Ad esempio, esegui il comando nslookup sul nome host con uno spazio

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Se anche il comando del sistema operativo nslookup non riesce a risolvere il nome host, la causa del problema è il nome host errato utilizzato per il server di destinazione.

Risoluzione

  1. Assicurati che il nome host del server di destinazione specificato nella configurazione dell'endpoint di destinazione o nella definizione del server di destinazione sia corretto e non contenga spazi o caratteri speciali indesiderati.
  2. Se utilizzi un criterio AssignMessage/JavaScript per generare dinamicamente il nome host del server di destinazione, esamina la definizione del criterio e il codice e assicurati che il nome host del server di destinazione venga generato correttamente.

Errori di handshake SSL

Un intero playbook per la risoluzione dei problemi è dedicato agli errori di handshake TLS/SSL. Consulta la sezione Errori di handshake SSL.

Determinare l'origine del problema

Alcuni tipi di errori possono verificarsi nella connessione in entrata (verso nord) o in uscita (verso sud). Si verifica un errore in entrata (in direzione nord) tra l'applicazione client e Edge. Si verifica un errore in uscita (verso sud) tra Edge e il server di destinazione di backend. Per diagnosticare questi tipi di problemi, la prima cosa da fare è capire se l'errore si verifica sulla connessione in uscita o in entrata.

Informazioni sulle connessioni in entrata e in uscita

In Edge, puoi riscontrare un errore 503 Servizio non disponibile nella connessione in entrata o in uscita:

  • Connessione in entrata (o in direzione nord): la connessione tra l'applicazione client e l'Edge Router. Il router è il componente di Apigee Edge che gestisce le richieste in entrata effettuate al sistema.
  • Connessione in uscita (o in direzione sud): la connessione tra il processore di messaggi Edge e il server di backend. Il processore di messaggi è un componente di Apigee Edge che funge da proxy per le richieste API ai server di destinazione di backend.

Se sei un utente di Edge Public Cloud, probabilmente non conosci i componenti interni come il router o il processore di messaggi. Questi componenti interni non sono visibili né accessibili agli utenti di Public Cloud. Ove possibile, forniamo modi alternativi per analizzare il problema che non richiedono l'accesso diretto a questi componenti.

La figura seguente illustra le connessioni in entrata e in uscita per Apigee Edge.

Flusso dell'applicazione client (connessione in ingresso) tramite Edge al server di backend (connessione in uscita)

Determinare dove si è verificato l'errore 503 - Servizio non disponibile

Utilizza una delle seguenti procedure per determinare se si è verificato l'errore 503 Service Unavailable nella connessione in uscita o in entrata.

Traccia UI

Per determinare dove si è verificato l'errore utilizzando UI Trace:

  1. Se il problema è ancora attivo, abilita la traccia dell'interfaccia utente per l'API interessata.
  2. Se la traccia dell'interfaccia utente per la richiesta API non riuscita mostra che l'errore 503 Service Unavailable si verifica durante il flusso della richiesta di destinazione o viene inviato dal server di backend, il problema è in uscita (ovvero tra il processore di messaggi e il server di backend).
  3. Se non ricevi la traccia per la chiamata API specifica, il problema è inbound, tra l'applicazione client e il router.

Monitoraggio delle API

Il monitoraggio delle API ti consente di isolare rapidamente le aree problematiche per diagnosticare errori, problemi di prestazioni e latenza e la loro origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Segui uno scenario di esempio che mostra come risolvere i problemi 5xx con le API utilizzando API Monitoring. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di errori messaging.adaptors.http.flow.ServiceUnavailable supera una determinata soglia.

Log degli accessi NGINX

Per determinare dove si è verificato l'errore utilizzando UI Trace:

Se il problema si è verificato in passato o se è intermittente e non riesci a a acquisire la traccia, segui questi passaggi:

  1. Controlla i log degli accessi NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log).
  2. Cerca eventuali errori 503 per un proxy API specifico.
  3. Se riesci a identificare eventuali errori 503 per l'API specifica in un momento specifico, il problema si è verificato nella connessione in uscita (tra il processore di messaggi e il server di backend).
  4. In caso contrario, il problema si è verificato nella connessione in uscita (tra l'applicazione client e il router).