这问题我碰到过好几次，虽然你说两台服务器配置完全一致，但十有八九是编码相关的隐性差异在搞鬼，下面是几个靠谱的排查和解决方向：

1. 强制指定log4net Appender的编码 #

首先确认你的log4net配置文件里，负责输出日志的Appender（比如常用的RollingFileAppender）有没有明确设置编码属性。很多时候默认编码会依赖系统环境，导致跨服务器不一致。

你需要在Appender节点里加上：

<encoding value="utf-8" />

比如完整的RollingFileAppender配置片段：

<appender name="RollingFileAppender" type="log4net.Appender.RollingFileAppender">
  <file value="logs/app.log" />
  <appendToFile value="true" />
  <rollingStyle value="Size" />
  <maxSizeRollBackups value="10" />
  <maximumFileSize value="10MB" />
  <staticLogFileName value="true" />
  <!-- 关键：明确指定编码 -->
  <encoding value="utf-8" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="[%level] [%date] [%thread] [%logger] [%method] - %message%newline" />
  </layout>
</appender>

另外还要注意配置文件本身的编码：把第二台服务器上的log4net配置文件用记事本打开，选择「另存为」，编码选UTF-8，覆盖原文件后重启应用试试。

2. 检查服务器系统的区域语言设置 #

如果配置文件没问题，那大概率是系统层面的编码差异。第二台服务器的「非Unicode程序语言」设置可能和第一台不一样：

• 打开控制面板 → 区域 → 管理选项卡 → 点击「更改系统区域设置」
• 对比两台服务器的这个选项，尽量设置成一致（比如都选「中文(简体，中国)」或者对应你的业务语言）
• 修改后需要重启服务器生效

log4net在没有指定编码时，会默认使用系统的ANSI编码，当系统编码和日志内容的编码不匹配时，就会出现乱码。

3. 验证日志文件的打开编码 #

有时候不是日志生成时乱码，而是你打开日志的工具用错了编码。比如用Windows自带的记事本打开，它会自动猜测编码，但可能猜错。

建议用Notepad++打开第二台的日志文件，在顶部「编码」菜单里切换不同的编码（比如UTF-8、GBK、ASCII），看看能不能正常显示。如果切换到某个编码后正常，说明是打开工具的问题，而非log4net的配置问题。

4. 排查IIS应用程序池的隐性设置（Web应用场景） #

如果是Web应用部署在IIS上，还要检查应用程序池的设置：

• 确认两台服务器的应用程序池.NET版本、32位模式启用状态完全一致
• 检查web.config里的<globalization>节点，是否指定了fileEncoding或responseEncoding，比如：

<system.web>
  <globalization fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>

这个节点的编码设置也可能间接影响log4net的日志输出编码。

先从指定log4net编码开始排查，这个是最直接的解决方案，大部分情况都能搞定。

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