Introduction

Yes, you can run Kafka inside WSL and connect to it from a producer running on Windows. The part that usually breaks is not the producer code. It is Kafka broker networking, especially listeners and advertised.listeners.

Kafka clients do not just connect to the bootstrap address you type. After that first connection, the broker tells the client where to connect next. If Kafka advertises a hostname or IP that Windows cannot reach, the producer fails even though the first socket test looked fine.

The Core Networking Rule

For a Windows producer talking to Kafka inside WSL, the broker must advertise an address that Windows can actually use.

For local development, the simplest choice is often localhost.

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://localhost:9092

This does two different jobs:

• 'listeners tells Kafka where to bind'
• 'advertised.listeners tells clients what address to use after bootstrap'

If you leave advertised.listeners pointing at a Linux-only hostname or an internal WSL address, the Windows client may connect once and then fail on metadata-based reconnects.

Start Kafka in WSL

For a local dev setup, run Kafka normally inside WSL.

bin/kafka-server-start.sh config/server.properties

Then confirm the port is actually listening:

ss -ltnp | grep 9092

If you are using an older ZooKeeper-based setup, start ZooKeeper first. If you are using a newer KRaft-based setup, make sure the broker configuration matches that mode.

The producer-side networking idea stays the same either way.

Test Reachability from Windows

Before writing any producer code, confirm that Windows can hit the broker.

Test-NetConnection localhost -Port 9092

If that fails, there is no point debugging Kafka client code yet.

On many WSL2 setups, Windows-to-WSL localhost forwarding works automatically for local development. If it does not, you may need to use the current WSL IP address instead and advertise that address consistently.

Java Producer on Windows

Once the broker advertises a reachable address, the Java producer is ordinary Kafka client code.

1import org.apache.kafka.clients.producer.KafkaProducer;
2import org.apache.kafka.clients.producer.ProducerRecord;
3import java.util.Properties;
4
5public class ProducerApp {
6    public static void main(String[] args) {
7        Properties props = new Properties();
8        props.put("bootstrap.servers", "localhost:9092");
9        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
10        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
11
12        try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
13            producer.send(new ProducerRecord<>("test", "key", "hello from Windows"));
14            producer.flush();
15        }
16    }
17}

If the broker metadata is correct, this code does not care that Kafka is running inside WSL instead of on native Linux.

Create a Topic and Verify End to End

Inside WSL, create and inspect a test topic.

bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092 --partitions 1 --replication-factor 1
bin/kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server localhost:9092

Then run the Windows producer. If the message appears in the consumer, the cross-environment setup is correct.

Common Pitfalls

The biggest mistake is misconfiguring advertised.listeners. It is the first thing to check whenever the producer can reach the bootstrap broker but still fails afterward.

Another common issue is mixing localhost, WSL hostnames, and dynamic WSL IPs inconsistently. Pick one address strategy and use it everywhere.

People also forget Windows firewall or VPN software, which can interfere with local port forwarding and make the problem look like a Kafka bug.

Finally, do not debug Java producer code before validating plain TCP reachability. If Test-NetConnection fails, the problem is below the application layer.

Summary

• Kafka can run in WSL while a producer runs on Windows.
• The critical setting is advertised.listeners.
• For local development, advertised.listeners=PLAINTEXT://localhost:9092 is often the simplest working choice.
• Verify TCP connectivity from Windows before debugging client code.
• Use a simple producer and console consumer to test the setup end to end.
• If bootstrap works once and then fails, the advertised broker address is the first suspect.