这个问题的核心原因很明确：Azure App Service的EasyAuth代理会在x-forwarded-for请求头中传入一串逗号分隔的IP（代理链的IP地址），而GeoServer的BruteForce安全监听器在尝试解析这个头作为客户端IP时，使用的Spring Security IpAddressMatcher类只能处理单个IP或CIDR格式的地址，无法解析逗号分隔的多IP列表，直接抛出了IllegalArgumentException导致登录失败。

下面分两种方案解决，先给快速登录的临时方案，再给长期的正确配置方案：

临时方案：禁用BruteForce的IP白名单检查（快速恢复登录） #

因为你现在无法登录GeoServer后台，需要直接修改配置文件：

1. 登录Azure Portal，进入你的App Service，找到高级工具（也就是Kudu控制台），点击「Go」进入。
2. 在Kudu的文件管理器中，导航到GeoServer的数据目录下的安全配置文件夹：
   • 如果是WAR包部署到Tomcat，路径通常是/home/site/wwwroot/webapps/geoserver/data/security
   • 如果是独立部署的GeoServer，路径可能是/home/site/wwwroot/geoserver/data/security（根据你的实际部署调整）
3. 找到bruteforce.properties文件：
   • 如果文件不存在，直接创建一个新的
   • 如果文件已存在，打开编辑
4. 添加或修改以下配置项：

   bruteforce.ipWhitelistEnabled=false
   

5. 保存文件后，回到Azure Portal重启你的App Service。

完成后，你应该可以正常使用GeoServer默认凭证登录后台了。

长期方案：配置Tomcat识别代理IP，传递正确的客户端IP给GeoServer #

为了从根源解决问题，需要让Tomcat信任Azure的代理，并将x-forwarded-for头中的第一个IP作为真实客户端IP传递给GeoServer，这样BruteForce监听器就能正确解析IP了：

1. 还是在Kudu控制台中，导航到Tomcat的配置目录，比如/home/site/wwwroot/conf（如果是App Service自带的Tomcat，路径可能是/usr/local/tomcat/conf，具体可以看App Service的Tomcat版本配置）
2. 打开server.xml文件，找到<Engine>标签（通常在<Service>标签内部）
3. 在<Engine>标签内添加以下RemoteIpValve配置：

   <Valve className="org.apache.catalina.valves.RemoteIpValve"
          remoteIpHeader="x-forwarded-for"
          protocolHeader="x-forwarded-proto"
          internalProxies="10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|172\.1[6-9]\.\d+\.\d+|172\.2[0-9]\.\d+\.\d+|172\.3[0-1]\.\d+\.\d+" />
   

   这里的internalProxies包含了Azure App Service常用的内部私有IP段，确保Tomcat信任这些代理来源的转发头。
4. 保存文件后重启App Service。

之后，GeoServer拿到的客户端IP就是x-forwarded-for中的第一个有效IP，BruteForce监听器就能正常解析，你也可以在GeoServer后台的Security > Brute Force页面正常配置IP白名单了（注意白名单中的IP要使用单个IP或CIDR格式，比如1.2.3.4或192.168.0.0/24）。

内容的提问来源于stack exchange，提问作者Ralph