Linux Commands Examples

A great documentation place for Linux commands


NC(1) BSD General Commands Manual NC(1) nc — arbitrary TCP and UDP connections and listens

see also : cat - ssh


nc [-46bCDdhklnrStUuvZz] [-I length] [-i interval] [-O length] [-P proxy_username] [-p source_port] [-q seconds] [-s source] [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol] [

-x proxy_address[
:port] ] [destination] [port]

add an example, a script, a trick and tips

: email address (won't be displayed)
: name

Step 2

Thanks for this example ! - It will be moderated and published shortly.

Feel free to post other examples
Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!


netcat -i 1 -l -p 9764 -u | netcat -v -u 9764

Sending file via netcat

Start another instance of netcat on computer B. Just do what you did on computer A, but serve it from B. Give the new server a new port.


Sending text file contents to server using netcat?

If you are using the GNU version of netcat then you can use the -c flag to close the connection on EOF.

-c, --close close connection on EOF from stdin

If you are using the original version of the tool then you can use the -q flag.

-q secs quit after EOF on stdin and delay of secs

An example for the original version is:

cat file.txt | nc -u -q 0 5144

I have add "-q 0" to your original command. This closes the connection after the file has been sent.


Use netcat as a proxy to log traffic

Use socat, you don't need the pipes and fifos


Open a TCP connection to port 42 of, using port 31337 as the source port, with a timeout of 5 seconds:

$ nc -p 31337 -w 5 42

Open a UDP connection to port 53 of

$ nc -u 53

Open a TCP connection to port 42 of using as the IP for the local end of the connection:

$ nc -s 42

Create and listen on a UNIX-domain stream socket:

$ nc -lU /var/tmp/dsocket

Connect to port 42 of via an HTTP proxy at, port 8080. This example could also be used by ssh(1); see the ProxyCommand directive in ssh_config(5) for more information.

$ nc -x10.2.3.4:8080 -Xconnect 42

The same example again, this time enabling proxy authentication with username ’’ruser’’ if the proxy requires it:

$ nc -x10.2.3.4:8080 -Xconnect -Pruser 42


Monitoring incoming requests on a web hosting server

I think its not possible. You have to ask the godaddy server to do the same for you and if allowed they will surely do it for you.

rlwrap netcat localhost 23753
numerorandom /teste.txt
echo "Chatting using 'netcat' through 'TCP' port $PORT "
netcat -l $PORT

How can I force netcat to send my input immediately, not just on newlines?

Use the "eof" key, CtrlD. When pressed in the middle of a line, it will give to netcat everything that has been input at that point.


Use xargs to send requests to the same server in parallel with netcat

Use echo -n or you will get 5 connections instead four, one of them with no data. If in the server this is not checked, maybe it is causing your problem.

echo -n A,B,C,D | xargs -d, -I{} -P 4 -n 1 echo {} | nc localhost 7000

Moreover, using a netcat as listening server, it appears to work right:

zhen@sydow:~$ nc -l 7000

And also it seems to be parallel, I see out-of-order echo.


Netcat stops listening for UDP traffic

So there are multiple things called netcat; ubuntu even has /etc/alternatives symbolic-link-hackery for it.

I think part of your problem is that UDP doesn't do sessions; I've copied in part of the file /usr/share/doc/netcat-traditional/README.gz below which does a pretty good job of explaining.

UDP connections are opened instead of TCP when -u is specified. These aren't really "connections" per se since UDP is a connectionless protocol, although netcat does internally use the "connected UDP socket" mechanism that most kernels support. Although netcat claims that an outgoing UDP connection is "open" immediately, no data is sent until something is read from standard input. Only thereafter is it possible to determine whether there really is a UDP server on the other end, and often you just can't tell. Most UDP protocols use timeouts and retries to do their thing and in many cases won't bother answering at all, so you should specify a timeout and hope for the best. You will get more out of UDP connections if standard input is fed from a source of data that looks like various kinds of server requests.

OK so maybe that's not all that great of an explanation but it's what I could find.

If you haven't yet, you might want to experiment with any netcat options you can find that would have to do with waiting... have you experimented with:

  • using -l as well as -u to ensure you're in "listening" mode

  • -vv to see exactly what's happening

  • -q -1 ...which should "wait forever" even after receiving EOF (hopefully, listening again?)


How to pipe the output of a linux command back into the predecesssing command

Named pipes are your friend!

mkfifo ncloop
nc -l 8090 < ncloop | (read METHOD URI PROTOCOL ; echo "method: $METHOD" ; echo "path: $URI" ; echo "prot: $PROTOCOL") > ncloop

(Tested in OS X 10.8.2 but should work on any Unix.)


Unix bidirectional pipe on commandline

Netcat documentation says

To obtain a hex dump file of the data sent either way, use "-o logfile". The dump lines begin with "<" or ">" to respectively indicate "from the net" or "to the net", and contain the total count per direction, and hex and ascii representations of the traffic. Capturing a hex dump naturally slows netcat down a bit, so don't use it where speed is critical.


Why is "nc -l xxxx" not opening a port?

I ran the verbose mode -v and got a clue back:

4444: inverse host lookup failed: Unknown server error : Connection timed out`
listening on [any] 41579 ...`

so I tried specifying a port with -p like this nc -lvp 4444 and it works:

listening on [any] 4444 ...

Obviously I need to use -p with -l with this version of nc.

I'd love it if anyone could tell my why there is this difference. Am I running an old version? (-h reports v1.10-38)


How can I verify that a 1TB file transferred correctly?

Two options:

Use sha1sum


In some circumstances sha1sum is faster.

Use rsync

It will take longer to transfer, but rsync verifies that the file arrived intact.

From the rsync man page

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred...


Listen to port continuously and dump data to file

You must add an option to nc. The option depends on the version of nc you are running. For instance, in my case (Kubuntu), the option is -k. From the man page,

-k Forces nc to stay listening for another connection after its current connection is completed. It is an error to use this option without the -l option.

I cannot promise -k works (unless you are n Ubuntu, of course), you will have to search for something similar. For instance, on my Debian, -k does not exist, but you find:

-q seconds after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever


To check that it works, on one pc:

  nc -k -l 10000 > out.txt

On a second pc:

  echo Hello | nc IP_address_of_first_pc 10000

Issue the command above a few times, then interrupt the nc command on pc1, check number of lines in out.txt.


Can I pipe/redirect a console application through netcat so it can be used remotely?

Well, as documented in Wikipedia and netcat documentation, there is a -e option that causes it to spawn (execute) a program upon receipt of a connection, attaching the socket to stdin, stdout, and stderr of the process.  Example usage:

nc -l -pport_number-eprogram_name

Examples commonly show /bin/sh or bash being used as the program_name.  Use of this option is discouraged because it basically opens an anonymous, passwordless access portal into your machine.  Of course, this is mitigated by using a program with less power than the shell (one that doesn’t have the ability to escape to a shell), minimizing your use of it, and keeping it a secret.  Nonetheless, the original developers of netcat felt strongly enough that this option was a bad idea that they disabled it by default, and conditioned it under the “GAPING_SECURITY_HOLE” compilation option.  This is mentioned briefly in this NetCat Tutorial and other netcat documentation.

A Google search led me to discussions of this issue on other Stack Exchange sites: Stack Overflow and Server Fault.  Multiple contributors offered the following technique to do the same thing without using the -e option (i.e., in a version of netcat that has the -e option disabled):

On the server:
nc -l -pport_number<pipe_name  | program_name>pipe_name

On the client:
nc server_machine_name port_number

A couple of notes:

  • On some versions of netcat, -l implies -p, so you should say just -l and then the port number.
  • You might want to wrap your solution in a while true loop.

Netcat stops when in a detached session

netcat wants to send its stdin across the socket and print out the response, so it expects to have them both connected and active. I don't know a good way of creating a command that waits forever, but you could try

sleep 86400000 | nc localhost 3000 > test.txt &


The nc (or netcat) utility is used for just about anything under the sun involving TCP, UDP, or UNIX-domain sockets. It can open TCP connections, send UDP packets, listen on arbitrary TCP and UDP ports, do port scanning, and deal with both IPv4 and IPv6. Unlike telnet(1), nc scripts nicely, and separates error messages onto standard error instead of sending them to standard output, as telnet(1) does with some.

Common uses include:

simple TCP proxies

shell-script based HTTP clients and servers

network daemon testing

a SOCKS or HTTP ProxyCommand for ssh(1)

and much, much more

The options are as follows:


Forces nc to use IPv4 addresses only.


Forces nc to use IPv6 addresses only.


Allow broadcast.


Send CRLF as line-ending.


Enable debugging on the socket.


Do not attempt to read from stdin.


Prints out nc help.

-I length

Specifies the size of the TCP receive buffer.

-i interval

Specifies a delay time interval between lines of text sent and received. Also causes a delay time between connections to multiple ports.


Forces nc to stay listening for another connection after its current connection is completed. It is an error to use this option without the -l option.


Used to specify that nc should listen for an incoming connection rather than initiate a connection to a remote host. It is an error to use this option in conjunction with the -p, -s, or -z options. Additionally, any timeouts specified with the -w option are ignored.


Do not do any DNS or service lookups on any specified addresses, hostnames or ports.

-O length

Specifies the size of the TCP send buffer.

-P proxy_username

Specifies a username to present to a proxy server that requires authentication. If no username is specified then authentication will not be attempted. Proxy authentication is only supported for HTTP CONNECT proxies at present.

-p source_port

Specifies the source port nc should use, subject to privilege restrictions and availability.

-q seconds

after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.


Specifies that source and/or destination ports should be chosen randomly instead of sequentially within a range or in the order that the system assigns them.


Enables the RFC 2385 TCP MD5 signature option.

-s source

Specifies the IP of the interface which is used to send the packets. For UNIX-domain datagram sockets, specifies the local temporary socket file to create and use so that datagrams can be received. It is an error to use this option in conjunction with the -l option.

-T toskeyword

Change IPv4 TOS value. toskeyword may be one of critical, inetcontrol, lowcost, lowdelay, netcontrol, throughput, reliability, or one of the DiffServ Code Points: ef, af11 ... af43, cs0 ... cs7; or a number in either hex or decimal.


Causes nc to send RFC 854 DON’T and WON’T responses to RFC 854 DO and WILL requests. This makes it possible to use nc to script telnet sessions.


Specifies to use UNIX-domain sockets.


Use UDP instead of the default option of TCP. For UNIX-domain sockets, use a datagram socket instead of a stream socket. If a UNIX-domain socket is used, a temporary receiving socket is created in /tmp unless the -s flag is given.

-V rtable

Set the routing table to be used. The default is 0.


Have nc give more verbose output.

-w timeout

Connections which cannot be established or are idle timeout after timeout seconds. The -w flag has no effect on the -l option, i.e. nc will listen forever for a connection, with or without the -w flag. The default is no timeout.

-X proxy_protocol

Requests that nc should use the specified protocol when talking to the proxy server. Supported protocols are ’’4’’ (SOCKS v.4), ’’5’’ (SOCKS v.5) and ’’connect’’ (HTTPS proxy). If the protocol is not specified, SOCKS version 5 is used.

-x proxy_address[

Requests that nc should connect to destination using a proxy at proxy_address and port. If port is not specified, the well-known port for the proxy protocol is used (1080 for SOCKS, 3128 for HTTPS).


DCCP mode.


Specifies that nc should just scan for listening daemons, without sending any data to them. It is an error to use this option in conjunction with the -l option.

destination can be a numerical IP address or a symbolic hostname (unless the -n option is given). In general, a destination must be specified, unless the -l option is given (in which case the local host is used). For UNIX-domain sockets, a destination is required and is the socket path to connect to (or listen on if the -l option is given).

port can be a single integer or a range of ports. Ranges are in the form nn-mm. In general, a destination port must be specified, unless the -U option is given.


UDP port scans using the -uz combination of flags will always report success irrespective of the target machine’s state. However, in conjunction with a traffic sniffer either on the target machine or an intermediary device, the -uz combination could be useful for communications diagnostics. Note that the amount of UDP traffic generated may be limited either due to hardware resources and/or configuration settings.

BSD July 18, 2013 BSD

client server model

It is quite simple to build a very basic client/server model using nc. On one console, start nc listening on a specific port for a connection. For example:

$ nc -l 1234

nc is now listening on port 1234 for a connection. On a second console (or a second machine), connect to the machine and port being listened on:

$ nc 1234

There should now be a connection between the ports. Anything typed at the second console will be concatenated to the first, and vice-versa. After the connection has been set up, nc does not really care which side is being used as a ’server’ and which side is being used as a ’client’. The connection may be terminated using an EOF (’^D’).

There is no -c or -e option in this netcat, but you still can execute a command after connection being established by redirecting file descriptors. Be cautious here because opening a port and let anyone connected execute arbitrary command on your site is DANGEROUS. If you really need to do this, here is an example:

On ’server’ side:

$ rm -f /tmp/f; mkfifo /tmp/f
$ cat /tmp/f | /bin/sh -i 2>&1 | nc -l 1234 > /tmp/f

On ’client’ side:

$ nc 1234
$ (shell prompt from

By doing this, you create a fifo at /tmp/f and make nc listen at port 1234 of address on ’server’ side, when a ’client’ establishes a connection successfully to that port, /bin/sh gets executed on ’server’ side and the shell prompt is given to ’client’ side.

When connection is terminated, nc quits as well. Use -k if you want it keep listening, but if the command quits this option won’t restart it or keep nc running. Also don’t forget to remove the file descriptor once you don’t need it anymore:

$ rm -f /tmp/f

data transfer

The example in the previous section can be expanded to build a basic data transfer model. Any information input into one end of the connection will be output to the other end, and input and output can be easily captured in order to emulate file transfer.

Start by using nc to listen on a specific port, with output captured into a file:

$ nc -l 1234 > filename.out

Using a second machine, connect to the listening nc process, feeding it the file which is to be transferred:

$ nc 1234 <

After the file has been transferred, the connection will close automatically.

port scanning

It may be useful to know which ports are open and running services on a target machine. The -z flag can be used to tell nc to report open ports, rather than initiate a connection. Usually it’s useful to turn on verbose output to stderr by use this option in conjunction with -v option.

For example:

$ nc -zv 20-30
Connection to 22 port [tcp/ssh] succeeded!
Connection to 25 port [tcp/smtp] succeeded!

The port range was specified to limit the search to ports 20 - 30, and is scanned by increasing order.

You can also specify a list of ports to scan, for example:

$ nc -zv 80 20 22
nc: connect to 80 (tcp) failed: Connection refused
nc: connect to 20 (tcp) failed: Connection refused
Connection to port [tcp/ssh] succeeded!

The ports are scanned by the order you given.

Alternatively, it might be useful to know which server software is running, and which versions. This information is often contained within the greeting banners. In order to retrieve these, it is necessary to first make a connection, and then break the connection when the banner has been retrieved. This can be accomplished by specifying a small timeout with the -w flag, or perhaps by issuing a "QUIT" command to the server:

$ echo "QUIT" | nc 20-30
Protocol mismatch.
220 IMS SMTP Receiver Version 0.84 Ready

talking to servers

It is sometimes useful to talk to servers ’’by hand’’ rather than through a user interface. It can aid in troubleshooting, when it might be necessary to verify what data a server is sending in response to commands issued by the client. For example, to retrieve the home page of a web site:

$ printf "GET / HTTP/1.0\r\n\r\n" | nc 80

Note that this also displays the headers sent by the web server. They can be filtered, using a tool such as sed(1), if necessary.

More complicated examples can be built up when the user knows the format of requests required by the server. As another example, an email may be submitted to an SMTP server using:

$ nc [-C] localhost 25 << EOF
MAIL FROM:<user[:at:]host.example[:dot:]com>
RCPT TO:<user2[:at:]host.example[:dot:]com>
Body of email.

see also

cat , ssh


Original implementation by *Hobbit* ⟨ hobbit[:at:]avian[:dot:]org⟩ .
Rewritten with IPv6 support by Eric Jackson <ericj[:at:]monkey[:dot:]org>.
Modified for Debian port by Aron Xu ⟨ aron[:at:]debian[:dot:]org⟩ .

How can this site be more helpful to YOU ?

give  feedback