reverso keepalive httpd example configurar conf apache2 tomcat7 mod-proxy proxypass

keepalive - proxypass apache2



Ajp mensaje inválido recibido con firma (5)

No hay solicitudes enviadas a la web o al servidor Tomcat y todavía produce ese error. Los registros de acceso en tomcat y apache muestran que no se recibe ninguna solicitud. ¿Qué está causando el error de mensaje no válido?

Solo una sugerencia para otras personas porque olvidé lo mismo en una de mis configuraciones por accidente: El Connector mencionado en server.xml está escuchando a nivel mundial, porque solo se especifica el port , sin ninguna address . Este último está definido para escuchar globalmente por defecto:

De forma predeterminada, este puerto se utilizará en todas las direcciones IP asociadas con el servidor.

https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Por lo tanto, sin un firewall adicional o tal, podría ser que los malos clientes simplemente estén probando los puertos abiertos que usan varios protocolos, que pueden ser HTTP o no y, por lo tanto, dar lugar a mensajes de error con diferentes firmas. Sin buenas razones, no debería haber ninguna necesidad de hacer que AJP esté disponible globalmente, especialmente en el caso de una configuración de proxy como la que utiliza el iniciador de hilos.

<Connector address="localhost" port="port" protocol="org.apache.coyote.ajp.AjpNioProtocol" connectionTimeout="20000" acceptorThreadCount="2" maxThreads="1600" redirectPort="8443" />

Estoy usando Tomcat 7.0.29 con el modproxy Apache 2.2.22. Configuró Ajp como el protocolo en httpd.conf y AjpNioProtocol en server.xml. Una vez que se inicia el servidor, los registros se llenan con el siguiente mensaje:

Grave: mensaje no válido recibido con la firma 20599
com.apache.coyote.ajp.AjpMessage processHeader

No hay solicitudes enviadas a la web o al servidor Tomcat y todavía produce ese error. Los registros de acceso en tomcat y apache muestran que no se recibe ninguna solicitud. ¿Qué está causando el error de mensaje no válido?

Aquí está la configuración:

  • httpd.conf

    ProxyPass /wl ajp:// ip : port /wl ProxyPassReverse /wl ajp:// ip : port /wl

  • server.xml

    <Connector port="port" protocol="org.apache.coyote.ajp.AjpNioProtocol" connectionTimeout="20000" acceptorThreadCount="2" maxThreads="1600" redirectPort="8443" />


Esto también puede ocurrir cuando los tamaños del búfer no son iguales en ambos extremos: los registros mencionan un mensaje AJP no válido y el navegador recibe un código de error 400 .

He solucionado la situación tanto con el packetSize de packetSize en el conector AJP y ProxyIOBufferSize en la configuración de Apache2.

En Tomcat server.xml :

<Connector protocol="AJP/1.3" port="8009" connectionTimeout="20000" packetSize="65536" proxyName="yourproxy.domain.ltd" proxyPort="80" />

En la configuración de Apache2 mod_proxy_ajp , agregue la declaración ProxyIOBufferSize 65536 .


Para mí, el problema era simple. Estaba enviando solicitudes HTTP pero el conector estaba configurado con el protocolo AJP. Mi conector en server.xml se configuró así:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>

Pero cuando lo cambié a esto:

<Connector port="8009" protocol="HTTP/1.1" redirectPort="8443"/>

El error se fue.

Esperemos que eso ayude a alguien con este error.


Recibí un mensaje similar hoy:

Nov 18, 2016 4:25:00 PM org.apache.coyote.ajp.AjpMessage processHeader SEVERE: Invalid message received with signature 65524

La causa raíz de mi problema fue que selinux no permitía que Apache se conectara con Tomcat. Estoy un poco confundido en cuanto a cómo este error fue el resultado: esperaría que no hubiera conexión, punto. La mejor conjetura, probablemente intenté conectarme manualmente a ese puerto con telnet. Hacer eso sin duda da un mensaje similar.

En cualquier caso, quizás este recordatorio de selinux sea útil para alguien que termine aquí.


Se encontró que uno de los procesos internos estaba llamando a ese puerto y enviando solicitudes http causando el error "Mensaje no válido ...". Así que terminé agregando un conector http adicional para esos procesos internos