Erro ao enviar NFe para SEFAZ/RS (HOM): Network subsystem is unusable

[Daniel Simoes]

1 hora atrás, leandrosouzadsv disse:

ACBr\Fontes\Terceiros\synalist\httpsend.pas

Identifiquei que o problema no FSock que esta destruido na primeira vez:

Fiz uma medida de contenção, esta funcionando.

if FSock.Socket = INVALID_SOCKET then
    FSock.CreateSocket;

function THTTPSend.InternalDoConnect(needssl: Boolean): Boolean;
begin
  Result := False;

  for var liTentativas := 1 to 3 do
  begin
    try
      FSock.CloseSocket;
      Sleep(300);

      if FSock.Socket = INVALID_SOCKET then
        FSock.CreateSocket;

      if FSock.LastError <> 0 then
        Continue;

      FSock.Bind(FIPInterface, cAnyPort);

      if FSock.LastError <> 0 then
        Continue;

      FSock.Connect(FTargetHost, FTargetPort);
      if FSock.LastError <> 0 then
      begin
        Sleep(500);
        Continue;
      end;

      if needssl then
      begin
        FSock.SSL.SNIHost := FTargetHost;
        FSock.SSLDoConnect;

        if FSock.LastError <> 0 then
        begin
          FSock.CloseSocket;
          Sleep(500);
          Continue;
        end;
      end;

      FAliveHost := FTargetHost;
      FAlivePort := FTargetPort;

      Result := True;
      Break;
    except
      FSock.CloseSocket;
      Sleep(500);
    end;
  end;
end;

 

Pode por favor, enviar a Unit modificada ?

[leandrosouzadsv]

Boa tarde.

 

httpsend.pas

[EMBarbosa]

Para quem está tendo problemas ainda. Aqui depois que eu atualizei o VCRedist, não tive mais problemas.

Eu atualizei usando winget. Como fazer:

1. abre um terminal, e executa

   winget upgrade

2. Vai dar uma lista de aplicativos e pacotes que podem atualizar. Verifique se vai aparecer VCRedist na lista como na imagem abaixo:
   
3. Se aparecer execute winget upgrade <NomeApplicativoOuIdAplicativo> para cada item da lista. Exemplo:

4. winget upgrade Microsoft.VCRedis.2015+.x86
   winget upgrade Microsoft.VCRedis.2015+.x64

Se isso funcionar para você, nos avise por favor.

[Daniel Simoes]

Aqui realmente o problema não pode mais se reproduzido, após atualizar o VCRedist

 

[Pedro Viero]

Estou com o mesmo problema, o update do winget não funcionou pra mim, porém ficar tentando algumas vezes funciona.

Editado 21 Maio por Pedro Viero

[Daniel Simoes]

Lembre-se de reiniciar o PC, após a atualização do VCRedist

[Pedro Viero]

Sim, fiz isso, dando um "winget upgrade" tenho esse Microsft Visual instalado, será que seria o caso de instalar o outro que tem na imagem do EMBarbosa?

[Nortesys]

Boa tarde,

DETALHE        : Erro Interno: 10091
Erro HTTP: 500
URL: https://nfce-homologacao.svrs.rs.gov.br/ws/NfeAutorizacao/NFeAutorizacao4.asmx
Network subsystem is unusable

tambem começou a acontecer o meu sistema, estou implementando em lazarus e esta em homolugação.

aguardando solução.

[Pedro Viero]

Fazendo a alteração do leandro para realizar as tentativas, funciona.

[Gandalf]

Boa tarde!

Há alguma desvantagem em usar Configuracoes.Geral.SSLHttpLib         := httpIndy;? Porque somente fazendo isso já solucionou o meu problema.

[Daniel Simoes]

Até onde sei, a Indy também usa OpenSSL... mas não funcionaria no Lazarus

[EMBarbosa]

21 horas atrás, Pedro Viero disse:

Sim, fiz isso, dando um "winget upgrade" tenho esse Microsft Visual instalado, será que seria o caso de instalar o outro que tem na imagem do EMBarbosa?

Se sua aplicação for 32 bits, precisa da versão 32 bits.

Ou seja, a versão .x86.

Edit: Mas notei agora que essa versão também não foi atualizada. É preciso.

[André Ferreira de Moraes]

Na minha máquina com Lazarus 3.2 acontece na primeira chamada tanto com OpenSSL quanto com WinCrypt.

Debugando a OpenSSL o erro é "10054-Connection reset by peer" que depois é sobrescrito pelo "10091-Network subsystem is unusable".

Com WinCrypt o erro é: "12030 - A conexão com o servidor foi redefinida ou encerrada, ou um protocolo SSL incompatível foi encontrado".

Em ambos os casos, se aguardar 60 segundos para fazer uma nova requisição o erro volta a ocorrer, se fizer chamadas seguidas o erro não ocorre. Com a dica para utilizar o winget upgrade acredito que o problema pode estar nas dlls vcruntime140.dll e msvcp140.dll.

Segue os arquivos que alterei da synapse para conseguir ver o erro real:
blcksock.passsl_openssl.pas

Adicionei também o httpsend para tentar fazer o retry igual sugerido anteriormente mas apenas se for o erro 10054: httpsend.pas

[Agnaldo Prates]

Já coloquei tentativas e nada. Em uma versão que não foi atualziada, está funcionando 100%, agora, depois que atualizei começou a oorrer erros no envio. TimeOut, já aumentei para 30.000 e nada. Deve haver alguma coisa nesta versão.

Em um cliente, a pasta shemas aparece /servidor/nfe/Schemas/ e está configurado para \servidor\nfe\Shemas\ aí, dispara o erro que não foi encontrado o tiposBasico_v4.00.xsd.

 

Editado 22 Maio por Agnaldo Prates

[Agnaldo Prates]

Serviço normalizado por aqui. Tudo indica que a pane era na Receita, mas o cenário mais grave é o silêncio do Estado.
O painel apontava que a disponibilidade estava Ok, mas nenhuma NF-e passava. Essa falta de transparência e respeito com quem desenvolve precisa mudar urgentemente. Não dá para aceitar que milhares de programadores fiquem caçando erros invisíveis no código enquanto o fisco esconde suas próprias falhas técnicas.

[EMBarbosa]

Em 22/05/2026 at 15:33, André Ferreira de Moraes disse:

Em ambos os casos, se aguardar 60 segundos para fazer uma nova requisição o erro volta a ocorrer, se fizer chamadas seguidas o erro não ocorre. Com a dica para utilizar o winget upgrade acredito que o problema pode estar nas dlls vcruntime140.dll e msvcp140.dll.

Me parece fazer muito sentido. Acredito que seja um bug levantado por uma condição específica da resposta do servidor.

Afinal estava ok e de repente começou. Então provavelmente algo mudou do lado do servidor que deixou o bug visível.

[Daniel Weber]

Bom estou com o mesmo problema vou colocar aqui algumas considerações para ver se ajuda em alguma coisa ...

1-tenho dois notebooks com win 11 pro em ambos não vai a NFCe em homologação RS, a NFe vai 100%
2-num dos notes tenho uma maquina virtual com win7 tb nfce nao vai e nfe vai
3-tenho um win server 2016 em um cloud, nele tanto nfce como nfe em homologação vão tranquilamente .

Não importa a configuração que se use, open, wincript etc... parece q o serviço funciona (pois eu testo com a funcao de verificar se serviço esta em operação e depois qndo vou emitir a nfce para)


Como sabemos tem o lance do SSL 1.2, agora que vem a coisa engraçada...
nos notes win 11 minhas opções de internet, ja tentei deixando o tls 1 e 1.1 marcados tbm e não adiantou, mas no caso dos win11 aparece esse tls 1.3


no win7 maquina virtual, mesmas configurações do ini do win server não vai tb de jeito nenhum

 

E agora o mais estranho de tudo no winserver

Quando aconteceu comigo o problema numa sexta feira as 3 da manha, eu estava emitindo nfce testando algumas outras funcionalidades e exatamente as 3 da manha comecou a dar erro
Eu acho que é no servidor da SEFAZ o erro, qndo comparei o arquivo do win11pro (o tls 1.3) e no winserver nao tem nem a opção de marcar, acredito q possa tambem ser alguma atualização do windos com esse protolo 1.3 mesmo não marcando.
E com relacao a maquina virtual eu acredito que como esta "hospedada" no win11 pro, possa ter baguncado

 

[EMBarbosa]

Em 29/05/2026 at 18:38, Daniel Weber disse:

Eu acho que é no servidor da SEFAZ o erro,

Boa tarde.

Pelo que entendemos nos nossos testes, esse problema tem pelo menos dois fatores: 1) alguma mudança do lado da sefaz, 2) um bug nas dlls da VCRedist

Sabemos que tem algo estranho do lado da Sefaz porque esse problema só acontece em homologação (ou seja é uma diferença do servidor e não do cliente), começou de uma hora para outra, sem nós fazermos nada e acontece só com a RS.

Mas também, como já relatado, quando se atualiza a VCRedist, tem resolvido o problema.

Pode haver outros fatores, mas não conseguimos identificar exatamente o que está ocorrendo nesse caso específico ... 

De qualquer maneira, atualizamos esse tópico aqui com informações sobre possíveis causas e soluções.

Em 29/05/2026 at 18:38, Daniel Weber disse:

nos notes win 11 minhas opções de internet

essas configurações de internet não afetam a OpenSSL. Então se estiver usando a OpenSSL, pode ignorá-las.

Em 29/05/2026 at 18:38, Daniel Weber disse:

qndo comparei o arquivo do win11pro (o tls 1.3) e no winserver nao tem nem a opção de marcar, acredito q possa tambem ser alguma atualização do windos com esse protolo 1.3 mesmo não marcando.
E com relacao a maquina virtual eu acredito que como esta "hospedada" no win11 pro, possa ter baguncado

E acho difícil ser isso, porque não recebemos nenhum aviso de mudança para outro protocolo. Esse tipo de mudança é avisado para evitar possíveis problemas.

Mas com relação a sua máquina virtual, seria "fácil" você testar sua teoria, copiando a máquina virtual para o windows server.

[Daniel Weber]

Boa tarde/noite ... @EMBarbosa

Consegui voltar a emitir nfce no ambiente homologação.
Conforme o tópico 
computadores win11 - Baixei as versoes da dll da trunk (porem apenas funcionou qndo eu baixei as versoes x86 ) mesmo sendo SO x64, o VCRedist estava atualizado;
computador maquina virtual win7 - baixei as dlls v86 e coloquei no so x64, porem no win7 eu tive que instalar o VCRedist (x64), preferi baixar os instaladores diretos no link
https://www.microsoft.com/pt-br/download/details.aspx?id=52685

Configuração da dll (alem do tls 1.2)

Porém reiniciei o computadores e o erro voltou a ocorrer.

Ai estranhamente eu entro novamente na tela de config da dll, e apenas dou um gravar ... e vou na emissao da nfce e retransmito e vai...
Não sei se é apenas acaso ou o servidor da sefaz ta com alguma intermitência horas responde horas nao responde.

 

[Juliomar Marchetti]

5 horas atrás, Daniel Weber disse:

computadores win11 - Baixei as versoes da dll da trunk (porem apenas funcionou qndo eu baixei as versoes x86 ) mesmo sendo SO x64, o VCRedist estava atualizado;

Sim. esse caso sempre possui confusão. deve seguir a arquitetura de sua aplicação e não do sistema operacional. no caso seu sistema é x86 = Win32.

5 horas atrás, Daniel Weber disse:

computador maquina virtual win7 - baixei as dlls v86 e coloquei no so x64, porem no win7 eu tive que instalar o VCRedist (x64), preferi baixar os instaladores diretos no link

Hum. estranho precisar rodar com a versão x64 do VCRedist. pois ele vai seguir sua aplicação também. Mas Ok.

 

5 horas atrás, Daniel Weber disse:

Não sei se é apenas acaso ou o servidor da sefaz ta com alguma intermitência horas responde horas nao responde.

Sim. está parecendo algo assim. pois há relatos semelhantes, as vezes envia e as vezes dá o erro. 

[Prioriza Sistemas]

Bom dia. 

Acredito que tem algo do lado do servidor mesmo, desenvolvemos em PHP e não usamos Libs na emissao de NFCe nem NFe e estamos com o mesmo impasse.

O erro aparece tanto nas maquinas Linux e Windows que operam em ambiente homologação do ERP e consequentemente em homologação do SEFAZ RS.

[EMBarbosa]

2 horas atrás, Prioriza Sistemas disse:

desenvolvemos em PHP e não usamos Libs na emissao de NFCe nem NFe

O que vocês usam para construir a comunicação segura (TLS) e fazer o envio? 

[Prioriza Sistemas]

Bom voltando agora com mais informações porque corrigimos o problema.

O problema parece estar ligado a alguma atualização que passou a considerar por padrao o TLS 1.3, acredito que antes, o servidor não tinha isso como uma configração aceita, o que fazia automaticamente usar TLS 1.2, para corrigirmos aqui, forçamos o cURL que use TLS 1.2 e voltou a funcionar normalmente.

 

12 minutos atrás, EMBarbosa disse:

O que vocês usam para construir a comunicação segura (TLS) e fazer o envio? 

Nossa construção é baseada na NFePHP (sped-nfe), mas no fundo é tudo cURL: usamos os parâmetros de SSL para estabelecer o mTLS (certificado A1 como cert de cliente), assinamos o XML e o enviamos dentro de um envelope SOAP 1.2 via POST HTTPS

Qualquer coisa pode me chamar la no discord do ACBR José Alcides (josesoluct) que conversamos.

 

[Daniel Simoes]

O ACBr já tem um mecanismo para tentar novamente, a comunicação em caso de erros.. e ele deixa esse controle, para a aplicação

Por favor teste o seguinte, no evento OnTransmitError

procedure TfrmACBrNFe.ACBrNFe1TransmitError(const HttpError,
  InternalError: Integer; const URL, DadosEnviados, SoapAction: String;
  var Retentar: Boolean; var Tratado: Boolean);
begin
   Retentar := (InternalError = 10091) or (InternalError = 12030);
   Tratado := False;
end;